On Fri, Apr 3, 2020 at 2:37 PM Dirk Hohndel via subsurface
<[email protected]> wrote:
>
> I need to spend more time staring at the code to try to figure out how
> it's possible that we find two new dives but then believe that the dive
> list is unchanged - as THAT is the underlying problem here. Which is
> different from the problem we had with 3.0.x with x<3 where we thought
> that there was already a write ongoing and refused to start a "second"
> write...
Hmm. "move_dive_table()" (which does the "move from download thread to
main divelist) doesn't actually seem to do mark_divelist_changed().
So maybe that never happens, and then unsaved_changes() returns false,
and then we don't even try to save anything?
Back to merging kernel ARM code for me..
Linus
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
