"simultaneuous" edits not caught #2814

New Issue

meejah · 2016-08-29T20:18:45Z

meejah commented

2016-08-29 20:18:45 +00:00

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):

bob's uploader sees a new file called "foo" (locally created)
alice's uploader sees a new file called "foo" (locally created)
"foo" is not in the DMD for either Alice or Bob
creates a new entry (version 0) and uploads
whomever "wins" the upload, puts a "foo" of version 0 into the DMD
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)

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)

meejah added the

code-frontend-magic-folder

normal

defect

1.11.0

labels 2016-08-29 20:18:45 +00:00

meejah added this to the undecided milestone 2016-08-29 20:18:45 +00:00

meejah commented

2016-08-29 21:15:29 +00:00

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).

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).

meejah commented

2016-08-31 06:06:29 +00:00

Fixed in https://github.com/tahoe-lafs/tahoe-lafs/pull/325

Fixed in <https://github.com/tahoe-lafs/tahoe-lafs/pull/325>

meejah added the

fixed

label 2016-08-31 06:06:29 +00:00

meejah closed this issue

2016-08-31 06:06:29 +00:00

warner modified the milestone from undecided to 1.12.0

2016-09-02 17:25:03 +00:00

Sign in to join this conversation.