gnome-control-center expects to be able to re-enroll an existing print
when calling EnrollStart without deleting it first. As such, implicitly
delete the existing print rather than throwing an error.
Ideally, we'll change the API, but we need to give API users time to
adjust to the world.
If the device supports listing prints, then we can do more targeted
deletes once the storage runs out. As such, do not try to clear the
storage on first enroll (therefore allowing dual boot setups to work to
a limited degree).
Clear the device storage before we enroll the first print. At that
point, we know that the storage should be completely empty and we have
no way of deleting "garbage" prints later if the device does not support
listing prints.
Always do an identify step before starting an enroll. If we find an
existing print, delete or throw an error depending on what is
appropriate.
Doing this ensures that we should not get duplicate prints system wide.
This means we will be able to identify the user that is trying to log
in. But more importantly, we need to do these checks for MoC devices,
which always run "identify" against all device stored prints rather than
the passed gallery.
During VerifyStart we may return early if there are no enrolled prints.
In such case we don't require the verification to be stopped if we're
using identification, but in the verification case we may leave the
device into the verification state.
So ensure we only set the device current state only when we're about to
start it.
Add tests ensuring those cases
The user may have some invalid prints saved (like the ones enrolled with
fprintd 1) in the storage, this lead to list such prints as enrolled but
they're actually not valid.
So load the prints to ensure that those are of the valid type instead of
just discovering them.
We may make just store.discover_prints to be aware of this, but this
would break some assumptions we do in tests, so better to go this way.
When saving the prints we use g_file_set_contents under the hood and in
case return its error code that is a positive value.
So in such case we don't fail if we have a write failure at the end of
the enrollment.
While we could ensure in file storage to always return a negative value,
it's always better to ensure that is has to be 0 when we didn't get an
error.
Add a test checking for this case.
Since we so far we had no duplicated-check for prints in fprintd an user
may have enrolled the same print for multiple accounts or even for
different fingers, so we need to simulate this case.
Given that fprintd may not allow to enroll duplicated prints soon, it's
better to just copy the storage value so that we simulate a duplicated
enrollment in the past.
Allow to enroll multiple data in a single shot so that we don't have to
do it for each user, and add a test that uses it to match each possible
combination.
Some tests were delaying VerifyStop by not reporting the finger status
in the image driver, we can do the same using sleeps in the virtual
device driver, so let's reimplement such calls
Now that FPrintdVirtualStorageDeviceBaseTest is a
FPrintdVirtualDeviceBaseTest we can implement the needed `send_*`
functions that we use in the tests in order to get easily an interface
that can be used to repeat all the tests we've already written with the
new virtual device.
To do this, we've only to create new test classes that use the
FPrintdVirtualStorageDeviceBaseTest as main base class and that
also implement the test class.
When a device has reported the verification status the client should
call VerifyStop to stop the device, however this under the hood may lead
to a premature cancellation, causing the device not to react as expected
in case the finger is still on the sensor or in case it may return to us
some errors that we may want to handle (like the data-missing one).
So, in case we are about to stop the verification and the operation is
still in process, wait for a maximum timeout before proceed to the
cancellation.
However, while waiting, the action may be also cancelled because of a
call to Release() or because the client vanished, and in such case we
have to ensure that the current invocation is saved for being invoked by
stoppable_action_completed() when callback will return. That will also
unset it, and that's a clear indication for us that it has been already
consumed, and thus that we can just return doing nothing else.
Fixes: #100
Some tests may have different behaviors depending on the CPU load when
using parallel tests, so async results could arrive in different order.
Then we need to accept multiple results:
- A specific exception has to happen all the times
- One of the accepted exception has to happen all the times
- No exception or one of the allowed exception may happen
Depending on the test, use one of the possible strategies.
