Garmin support: ignore FIT files that aren't dives
dirk at hohndel.org
Tue Sep 4 18:55:42 PDT 2018
> On Sep 4, 2018, at 6:47 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> On Tue, Sep 4, 2018 at 6:32 PM Dirk Hohndel <dirk at hohndel.org> wrote:
>>> On Sep 4, 2018, at 6:11 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
>>> I took all your commits. Minor changes, like not checking that
>>> device_index, because it actually changes *after* you've already seen
>>> the values.
>> As you have seen, there are several devices inside your Garmin.
> Yes, yes. But because you checked device_index, you actually got the
> *wrong* data.
I understand that - see my explanation that the fact that index 0 and 1
ended up having the same data... which is why I didn't notice this.
>> Clearly we need to use the device_info message that is for the correct device_index.
> No, we probably just need to use the *first* one.
> The fields inside the record aren't ordered (well, they are, but the
> ordering is an insane one based on the size of the field).
> But the various messages do end up being ordered. In fact, the FIT
> specification even enforces some of the index ordering, although it's
> not spelled out for the device_index one. But other index cases (the
> generic message index and part index) are literally specified that
> they have to start with zero and increment sequentially.
> So the assumption that device_index 0 is the first one is actually a
> fairly safe one just going by some of the other indexing FIT files do,
> unlike the assumption that device_index comes before the other fields
> (which is not only not safe, it's not actually the case).
I didn't find any mention that the indices are ordered. Feel free to
ignore the attached patch - but it seems a very small price to ensure
we don't use the data for a different device index by mistake.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the subsurface