read-only share: locally modified file mutliple times should create multiple conflict files (?)

[moscicki]

ownCloud 2.2.4 on MacOSX.

In read-only share I modified a file b.txt which was fully synchronized initially. I had to add the write-bit because it was read-only. The system tried to revert the file but since it found a modification it created a conflict file. The sync was green at the end. That's all expected.

%ls -l
   -r--r--r--  1 moscicki  staff  23 Aug 23 16:11 b.txt
   -rw-r--r--  1 moscicki  staff   2 Oct 25 13:23 b_conflict-20160823-161149.txt

When I then again modified file b.txt the system did not create the second conflict file as it should. Instead it left the b.txt modified locally. The resulting log was this:

When I subsequently removed the conflict file b.txt was restored from the server and a new conflict file created.

Should it create multiple conflict files in this cases to have consistent behaviour?

[ckamm]

@moscicki Yes, I agree there should be multiple conflict files. It seems to be using the mtime of the server's version of the file for the conflict file name.

[ckamm]

@dragotin @ogoffart @guruz What's the reason we use the server's timestamp during conflict file name creation? Wouldn't the local mtime work just as well? I'm wondering whether I should change this generally, and not just for restorations.

[ogoffart]

Yes, i suppose using the local time is actually better.

[ckamm]

Pull request including change and test: #5300

[SamuAlfageme]

@ckamm Yup, now the conflict files are created with the local timestamp (<file>_conflict-yyyyMMdd-HHmmss.<ext>) and the original file is restored, there are some overlay-related issues though:

• The ones in the conflict files are initially in 🔁 Syncing status until you close the folder and reopen it.
• The original file appears with the ⚠️ overlay as it's not being correctly synced (instead of the original shared green one). This one is kept even when you reopen the folder.

And then, one question. When I create a new file/folder in a read-only folder, it generates a Sync error (which btw, removes the previous conflict entry in the "Not synced" tab and replaces it by the one about the new sync error) - but this is semantically the same as adding a conflict file (that doesn't cause a sync error).

[ckamm]

@SamuAlfageme Conflict messages are currently not persistent, i.e. they are removed when the next sync is triggered and won't show up again. Since conflicts should almost always be resolved quickly by the user, that seems like a usability problem we'll want to address. (I'll add a note to #2766)

Adding a new file to a read-only folder and creating a conflict file inside it aren't equivalent, because conflict files are never synced, so by not syncing the conflict file no user expectations (that the file should be transfered to the sever) are violated.

The overlay issues you mention I'll move to a separate ticket since they're unrelated to this issue (nice catch!).