Sync conflict files?

[dniku]

When the client detects a conflict, it creates a new file called <filename>_conflict-<date>-<time>.<ext>. This file does not propagate from the machine where it is created (as of client 2.0.1 running under Kubuntu 15.04 and server 8.1.1). This may cause loss of data. For example, if I lose the device with the this file, this loss is irrecoverable.

[phil-davis]

And also that means that other people/client devices do not receive the conflict file and so those people/client devices are not aware of the conflict and thus cannot help to resolve it.

[ghost]

Hi,

seems thats the wanted behaviour when reading this correctly:

https://doc.owncloud.org/desktop/2.0/architecture.html#comparison-and-conflict-cases

From my PoV it makes no sense to move conflict files around. But if you want to have this you might still be able to edit the global ignore list.

But for the majority of the users this behaviour shouldn't be changed.

[dniku]

The conflict files may contain important information. I originally discovered the problem when I found a bunch of conflicts of my password database, which presumably meant that I added some passwords on one PC, then on another PC, then saved the database on the first, and finally saved it on the second.

[ghost]

If it contains useful info for you follow the advise above and remove the conflict files pattern from the global ignore list.

[dniku]

Thanks for the advice! I have followed it. However, I doubt whether it is a good idea to restrict conflict synchronization. The ownCloud docs do not specifically mention that the conflicts should not be synced:

The client resolves this conflict by creating a conflict file of the older of the two files and saving the newer file under the original file name. Conflict files are always created on the client and never on the server. The conflict file uses the same name as the original file, but is appended with the timestamp of the conflict detection.

My rationale is that the conflicts may contain useful data. Could you elaborate on why you consider it generally pointless to sync them?

[ghost]

Lets say you have a shared folder where 100 clients are syncing against. If one client creates an conflict this file would be synced to all 99 clients. You can guess what mess/confusion this can cause, especially if you have a lot of non-tech safe people.

I think the ignore pattern of the conflicts files also wasn't put into the sync-exclude.lst just for fun.

[dniku]

That's an interesting point. Do the other providers (Dropbox, Google Drive, Onedrive, Yandex.Disk) disable syncing conflicts too?

[ghost]

I think most of the people don't use other providers. If you have some spare time free feel free to do a test with other providers. :)

[blanik]

I did have another provider which synced conflict files to all users, so I ended up with file1 and file1(changed by bob) on all the computers.

The problem then is that sometime one user would delete the original file and rename 'bob', but someone else would look at 'bob', then save it, which was recorded as a change. So on the next sync I would end up with file1 ( changed by bob)(changed by john). Or the file1(changed by bob) would be deleted but one of the clients would upload it back to the server to be distributed again.

In the end I had to manage all conflicted files on the server, which included copying and deleting the files rather than renaming, to try and get all the clients back in step.

For a multi-user environment I think the owncloud solution of keeping the conflict locally and expecting the user who caused the conflict to sort out the files on his machine is better.

However I think that there needs to be better notification to the user that a conflict has occurred. Most of my non-technical users just run the client in the background. I just did https://guides.github.com/features/mastering-markdown/ a test and got no notice of a conflict - there is a 'conflict' file in the folder ( which they might not notice if they open recent files from word etc. ) and a message in the activity tab on the control panel, which they would not normally go into.

[jancborchardt]

As said in the past, I think it’s very important that the conflict files are synced. For reasons mentioned above: The file could get lost otherwise. Also, you’re able to resolve conflicts on other machines then.

I consider this very important – what do you think @dragotin @danimo @guruz @ogoffart

[danimo]

Of course we also checked what the competition does. Noone syncs conflict files. And it wouldn't make any sense. You'd get crazy pretty quickly as pointed out above. Conflicts need to be resolved locally. What we need to do instead is making sure to

• sync all files that the client can sync to the server, rather than only the files that can for sure synced by all clients (underway for 2.1)
• make it obvious that people understand the concept of conflicts, and that they are aware of it without them becoming too annoying.
• possibly be more clear as to why a conflict file is being created. Dropbox does that by appending the conflict reason to the file name, which doesn't always help, as the file name is elided in a lot of file views.

[dragotin]

No, no sync of conflict files.

[robertdusik]

Hi guys, I've read the conversation and I also think that syncing conflict files is a very important feauture and user should decide whether he wants to enable it or not. E.g.: I'm migrating corporate files (thousands) from GOOGLE DRIVE (google aps for business) to OWN CLOUD solution and I'm missing this feature very much. Google DRIVE allows to sync the CONFLICT files which allow the USER (or users) who produced the conflict to ENCOUNTER that the files is not OK before anyone else continues editting it. Imagine important .xls files with many data that has been "conflicted" without user (who made it happen) knowing it. It's not good. This information should be immediately notified to all users working with the file, so everybody knows that something is NOT OK before they continue working with the file. Conflict needs to be resolved first.

Q: IS it possible to enable this option or not? I'm using version 2.1.1 (build 5837) [of desktop client].

Thanks a lot.

[danimo]

@robertdusik No, we would need to implement this in both server and client. It's not just a simple config option.

[robertdusik]

@danimo Thanks for the quick response. I guess I have to weigh the pros and cons of the feature than :)

[robertdusik]

@danimo One more question: Is it possible to notify all the users (with file privilleges) that a file has been "conflicted" so they know that there is (at least) one user who has got a file with the conflict? It'd help other users to stop working with file before they resolve the conflict.

Thanks

[danimo]

@robertdusik No, The server doesn't know about the concept of 'conflicts', so it cannot notify about them.

[robertdusik]

@danimo: OK, but from a programmer's point of view. Why should it be a problem for a client to sync the conflict file? It's just another file which I want to sync with my colleagues. Just because it's been created by owncloud app sholdn't be a problem. It's like if I create a copy of a file (CTRL+C, CTRL+V). But for some (internal reason) you have deciced to sync-ingnore the file that is created as a conflict file.

Am I wrong? I'd really appreciate if this conflict files are synced (as any other created files).

[dragotin]

Related: #4557

[toddpfaff]

I believe it's a poor choice to not sync conflict files, and a particularly poor choice to hardcode this in the client such that it's not user configurable.

If, for example, a user has a legitimate file that is named:

_myconflict-is-important.txt

it is silently excluded from syncing.

Despite some comments above that seem to indicate that one could edit the exclude list so that conflict files are not excluded, that is certainly not the case in current versions of the client. Here's the client code, found in recent versions of client-master/csync/src/csync_exclude.c, where the hardcoded exclusion takes place:

/* Always ignore conflict files, not only via the exclude list */
rc = csync_fnmatch("*_conflict-*", bname, 0);
if (rc == 0) {
    match = CSYNC_FILE_SILENTLY_EXCLUDED;
    goto out;
}

It seems odd that this exclusion pattern isn't even as specific as the pattern used to create conflict files.

Of course, the obvious workaround to this current ownCloud client design flaw is to find and rename all files that match '_conflict-' to something that doesn't match that pattern and that doesn't conflict with other file names.

[guruz]

Uploading conflicts (experimental)

https://doc.owncloud.org/desktop/2.5/conflicts.html#uploading-conflicts-experimental

[robertdusik]

Great to know that. Please let me know as soon as this functionality is really deployed, not experimental.

Thanks. Robert

po 23. 7. 2018 o 16:06 Markus Goetz notifications@github.com napísal(a):

Uploading conflicts (experimental)

https://doc.owncloud.org/desktop/2.5/conflicts.html#uploading-conflicts-experimental https://mailtrack.io/trace/link/e9166d6516c00336ae3e5c6352f122e7a8c8598b?url=https%3A%2F%2Fdoc.owncloud.org%2Fdesktop%2F2.5%2Fconflicts.html%23uploading-conflicts-experimental&userId=2835668&signature=7ca6b77cca667cad

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://mailtrack.io/trace/link/7da9fa30e09669f5eaeb7031560444cac9e1f490?url=https%3A%2F%2Fgithub.com%2Fowncloud%2Fclient%2Fissues%2F3869%23issuecomment-407069811&userId=2835668&signature=27565257e9e15b9e, or mute the thread https://mailtrack.io/trace/link/686eacf1be6a449ed8b16694eb8aa94f5a480f98?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FARAbY1OqVfR68knlql_ULwO0YF5HptfQks5uJdhOgaJpZM4GAMYI&userId=2835668&signature=37c3303039e32519 .

[guruz]

@robertdusik It depends on the community (= your) testing :-) You can use the testpilotcloud branded client if you don't want to overwrite your client. https://central.owncloud.org/t/desktop-sync-client-2-5-0-beta1-released/14667