#2814 closed defect (fixed)

"simultaneuous" edits not caught

Reported by: meejah Owned by: daira
Priority: normal Milestone: 1.12.0
Component: code-frontend-magic-folder Version: 1.11.0
Keywords: Cc:
Launchpad Bug:

Description

If two paired magic folders both edit (or create) the same file at "the same time" (i.e. before they learn of the other side's edit) then no conflict is detected (and the file is not synchronized between the two sides).

I think what's happening is this (for the creation case, but same for a simultaneous edit):

  1. bob's uploader sees a new file called "foo" (locally created)
  2. alice's uploader sees a new file called "foo" (locally created)
  3. "foo" is not in the DMD for either Alice or Bob
  4. creates a new entry (version 0) and uploads
  5. whomever "wins" the upload, puts a "foo" of version 0 into the DMD
  6. the other side downloads the new DMD and sees a version 0 (and their local version is 0) so it decides "nothing to do".

(p.s. there's two integration tests for this in the new branch I pushed recently for magic-folder integration tests)

Change History (3)

comment:1 Changed at 2016-08-29T21:15:29Z by meejah

Really, I think this is actually another example of needing a better strategy than simple versioning. Also, it's really that we're not even downloading the other person's file (and therefore also not detecting a conflict).

When Alice and Bob see the new file, they both believe that it's new; so they both upload a "version=0" file. (So in their own private collective-dirs, they each create a new file). When they try to sync next, they both see that they other side has a "version=0" file (which is the same as the biggest version in their local database, so nothing to do).

What the "other" side really needs to determine what to do is something like a vector-clock, so they can tell "bob thought his file was new when he uploaded it" and then alice can conclude that it was a conflict (because she also though it was new).

In this particular case, it might be sufficient to record *whose* version is in the local database (rather than just the plain version). Then, bob or alice can correctly conclude that they need to download. (I.e. bob will see "bob's version 0" is what he has, but alice also has a version 0 so he can conclude that she uploaded her own version 0 before seeing his, or her version would be 1).

comment:2 Changed at 2016-08-31T06:06:29Z by meejah

  • Resolution set to fixed
  • Status changed from new to closed

comment:3 Changed at 2016-09-02T17:25:03Z by warner

  • Milestone changed from undecided to 1.12.0
Note: See TracTickets for help on using tickets.