Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:27 AM, Sébastien Dugué
<sebastien.dugue.subsurface at gmail.com> wrote:
> On Mon, Apr 23, 2018 at 7:07 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
>>
>> On most dive computers, it's 4 bytes, on others it's 5-6, and on some
>> it's 16 bytes of random binary data.
>
>   My bad, I assumed that feature was only present in the Uwatec DCs where it's
> a timestamp.
>
>   And I cannot imagine how something else might be useful for that purpose...

Well, the fingerprint can anything, which is part of the problem. It
can be an offset into the dive computer buffer. It could be just an
index into the dive computer dive table. It could be the first few
bytes of the dive download that contains the unparsed dive data (which
probably *includes* the dive date, but can have a internal dive
computer dive number)

So in practice it really is random data, and it's not useful to
subsurface directly. We actually do use it to generate a "dive ID"
(that is used to check for duplicates), but that is a fairly simple
and well-defined thing (it's the first four bytes of a SHA1 hash -
either of the fingerprint data, or if the dive computer gives a
particular "Dive ID" string.

And I *really* don't want to save it to our dive logs, because it's
not useful long-term. It's not useful to a user, but it's not even
useful to subsurface long term - only the last dive matters. So saving
it for every dive is fundamentally wrong - it's not how it would ever
be used.

But I think I've come up with an approach that is viable, exactly
*because* we do have a dive ID anyway. We can save the fingerprint
*and* the dive ID in the cache file, and then when we *use* the
fingerprint, we just verify that we have a dive that matches the dive
ID associated with that fingerprint.

So at worst, we'll never use the fingerprint at all, because the last
time somebody did a download, they didn't save the dives (or maybe
they just did't save them into the file we're now using, or didn't
save the *last* dive or whatever).

But then we're no worse off than we are now.

And if we *do* have the dive that is associated with the fingerprint,
then we'll use it, and only download new dives up until that point.

The attached patch seems to work in my (very limited!) testing.

Testers welcome. It should apply fine to any modern subsurface tree
(ie you don't have to have the "NG" branch, but it won't hurt, and
it's what I tested and used as a base).

                Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 6422 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180424/0c6f6f6a/attachment.bin>