[QA] Concurrent update and rename duplicates file

[jnweiger]

Seen while testing #8763 with 2.8.3.4442

• Connect a windows machine with client 2.8.3.4442 (without using winVFS) to demo@demo.owncloud.org
• Connect a linux machine with 2.8.2 (also not using VFS) to the same account.
• On the windows machine, open Documents/Example.odt with LibreOffice Writer, change a few lines and hit the save button.
• Very quickly afterwards(!) rename the file Documents/Example.odt on the Linux machine to Documents/Away.odt
• Wait until all syncs complete.
• On the Linux machine, Example.odt gets recreated (with the updated contents from LibreOffice), Away.odt remains there with the previous contents.

Expected behaviour: No duplication. The file with the new name should receive updates on the Linux. The updated file on the windows side should be renamed.

[TheOneRing]

@dragotin so rather than retrying to rename I assume I'd need to check where the file is lcoked BEFORE I try...

[TheOneRing]

I assume the same would happen with a 2.8.2.
I don't expect vfs to have an influence on this.

[jnweiger]

Re-Tested with 2.8.2.4461:

• Rename on the server immediatly after the client lock is released: We still get duplicate files. BAD
• Rename on the server before the client lock is released: we get duplicate files, as soon as the lock is released. BAD
• Rename of the parent folder on the server before the client lock is released: the rename correctly propagates to the client, as soon as the lock is released. OK

[TheOneRing]

After another debugging session with @jnweiger we can document the following behaviour.

Scenario A

• A locks
• B moves
  • on B: the file on system B is moved immediately
  • on A: nothing happens, as the file is locked
• A unlocks
  • on B: nothing happens
  • on A: the file is moved

-> Ok

Scenario B

• A locks
• B moves
  • on B: the file on system B is moved immediately
  • on A: nothing happens, as the file is locked
• B modifies the moved file
  • on B: the file is updated
  • on A: a file is created in the new location
• A unlocks
  • on B: nothing happens
  • on A: the unmodified file in the original location is deleted

-> Ok

Scenario C

• A locks
• B moves
  • on B: the file on system B is moved immediately
  • on A: nothing happens, as the file is locked
• B modifies the moved file
  • on B: the file is updated
  • on A: a file is created in the new location
• A modifies the original file
• on B: nothing happens
• on A: no update is populated as the file is locked
• A unlocks
  • on B: downloads the new file in the original location
  • on A: uploads the file in the original location

-> We branched the file and one will have no history

[michaelstingl]

After another debugging session with @jnweiger we can document the following behaviour.

Okay, fine 👍

[TheOneRing]

Closing.
Original issue has been fixed.
Scenario C is works as expect.

[jnweiger]

Retested with client 2.9.0 daily build 4808

• Open Example.odt in lowriter, change the heading, save. But keep the editor open.
• While the libreoffice file Example.odt is still locked on the windows machine, I rename the file through the Linux client to Away.odt
• Wait one minute
• The file Away.odt appears on the windows machine,

• Exit LibreOffice to releases the lock on Example.odt
• The updated Example.odt file is synced now to the Linux machines. Both clients now have both files.

[TheOneRing]

Please compare to #8765 (comment)

[jnweiger]

Compared. What I did is different:

Scenario D

• A locks
• B moves
  • on B: the file on system B is moved immediately
  • on A: nothing happens to the original file, but the move syncs as a copy to A.

IMO, Scenarios C and D should not happen. If that happens according to design, then the design is (IMO) broken.

[TheOneRing]

Your D sounds like my C
Well there is nothing we can do as long as we don't implement client side locking ourself