handling fingerprints

[Jef Driesen]

On 24/10/2021 02:12, Dirk Hohndel via subsurface wrote:
> (3) close the cloud storage, open a local .xml file; download again
>     -> fingerprint file is found, but the matching dive is not in the dive list, so fingerprint gets ignored (but why are we even looking at it???)
>     -> dives are downloaded, fingerprint is written again

What's the reason for ignoring the fingerprint if you don't have the 
corresponding dive anymore?

Assume you download your dives, and for some reason you don't want to keep the 
most recent dive in your logbook. Now, according to the above logic, the next 
time you download, you ignore the fingerprint because the dive isn't in the 
logbook and thus you'll re-download those old dives again, including the 
unwanted dive. For the dives that were already in your logbook, that's just 
inefficient, but they won't get added twice (I believe subsurface has some logic 
to prevent that). But that unwanted dive will re-appear, and you'll have to 
manually remove it again.

As a user, I would expect that the download resumes at the point where it 
stopped last time, regardless of whether I kept the previously downloaded dives 
or not. If I really want to re-download previously download dives, I can use the 
"Force download all dives" option, which disables the fingerprint logic.

Some example scenarios where you don't want to keep every dive recorded by your 
dive computer: If you have a watch style dive computer that you also uses as a 
watch, the watch may record activity in the pool as dives. Or someone doing both 
scuba and freedives may want to keep two separate logs.

> I am back to thinking that we should consider the fingerprint a property of a
> specific dive log. So both an XML file and the git storage should remember
> the last fingerprint for each dive computer from which we did a direct
> download. And we should index that exactly like we name these files in the
> filesystem right now - model.devinfo-serial - and then have the fingerprint
> data be a hex encoded byte stream of fingerprint-deviceid-diveid.
> 
> Sadly, this still causes pointless re-download orgies when a firmware change
> or some other change messes with the devinfo-serial number which we have to
> use as lookup parameter - but it seems like it would get more cases right
> than what we have today.
> 
> Of course, this all is triggered by the plight of specifically G2 users. And
> the annoying fact that even if they do the full download on a PC via cable,
> they still have to get a full download to work on their phone via BLE...
> 
> I'd much rather come up with a way to not rely on the devinfo-serial number,
> but at least on the G2 that one looks like it should be stable (there's no
> way to get the firmware version on the G2, it seems).

Why would a change in the firmware version cause a re-download? The serial 
number in the devinfo event is completely independent from the firmware version. 
Unless the device suddenly starts to report a different number, the serial 
number will not change after a firmware update. So it's as stable as it can be.

The devinfo serial number may indeed not match exactly with the serial number as 
printed on the device (due to some additional formatting which can't be 
represented by a simple 32bit number). But that's another story. The primary 
purpose of the serial number in the devinfo event (and the devinfo event itself) 
is to support the fingerprint feature: provide a unique ID to identify an 
individual device. For that purpose, it doesn't matter it doesn't exactly match 
the human readable serial number. It that sense it's like more an opaque ID, 
just like the fingerprint itself.

Of course, where possible we try to decode the serial number correctly. The 
reason why it's a 32bit number is historic. At the time this feature was added 
(more than 10 years ago), representing serial numbers as a 32bit integer was an 
obvious choice, because that's how dive computers stored it. Since then, there 
are many new dive computers that do things a bit different...

> I wonder if I am missing something in my model here... is there a scenario
> where storing the fingerprint with the dive log file creates incorrect
> behavior? At least for the important case (dive computer that supports both
> wired and BLE transfer - do the fast wired transfer on the PC and have the
> correct fingerprint for the next BLE transfer both locally AND and on the
> phone) this seems like it would be an improvement...

One scenario where you have to be careful is when the download failed. Because 
dives are downloaded in reverse order, you get the fingerprint of the most 
recent dives immediately with the first dive. But if you do update the 
fingerprint when some of the older dives failed to download, then you won't be 
able to retry and download those older dives without disabling the fingerprint 
again. So you should only update the fingerprint after a successful download, 
and deal with the duplicates after retrying.

Jef