When working with library from multiple devices - I very often got file conflicts, and Seafile creates SFConflict files for each conflict. Is it possible to implement mode when Seafile will create 2 new revisions of this one file, instead of creating file copy in filesystem with SFConflict suffix?
1 Like
I second this suggestion.
Its always puzzled me that none of the sync’ing applications dont just use their revision history mechanism rather than create a conflict file. A flag could be set in the revision history to say that it is a conflicted version to just make it absolutely clear.
This can be problematic for libraries that don’t keep a version history, or have a time limited one.
2 Likes
This can be implemented as Library option, not by default, and enabled only for libraries with enabled version history.
I think the idea behind creating a second conflict file is that Seafile has no idea which file is the one you would actually want to keep. So, hiding it behind a revision and just guessing (and it really is just a guess when Seafile doesn’t know which one is the latest version) makes it so that the user just expects it to have done the right thing.
Then, say the user doesn’t bother checking the file for a few months because they had no idea they don’t have the right one. Then history expiration comes around, the old revision gets removed, user comes back to actually use the file and whoops! There’s only half a book report there, not the whole one you were working on!
I am pushing back on this idea. I want a conflict file up front and center, in my face, so that I know there’s questions about which version of the file is the latest one. I don’t want it hidden behind a revision that can get expired out.
2 Likes
it’d be better if seafile were to put the conflict file in a different location or library. Maybe a “seafile-conflict” in the root path.
If a file lib1/pa/th/file.txt in library lib1 generates conflicts, it’s placed under lib1/seafile-conflict/pa/th/file.txt. That way you can stop seafile from generating files all over the place, and you still have them at hand.
btw syncing apps generate conflict files when they identify or are forced to fork the revision history, there’s no solution for that on a linal history.
If they are placed in a separate folder, how would the user know to go look in that folder to check for conflicts?
At least if they are placed in the same structure as the original file that generated the conflict they are easy to see and resolve.
I think having a notification pop up + the pretty explanatory name seafile-conflict is enough for users to know that there was a conflict and where it can be resolved. The other option is to have conflict files scattered all over the tree.
I suggest to make this optional per library, and not enabled by default.
In my cases most of conflicts are not serious (minor file changes), but every day I see a lot of SFConflict file duplicates, that waste space and file list, so I must remove it manually every day.
If you have so much conflicts, you’re making something wrong.
1 Like
@bionade24
I agree. I get them from time to time, but it usually happens when I have a power failure or dropped network connection during a sync. When the connection comes back up or the power restores, Seafile syncs the file again and realizes a conflict. The only other time I ever had conflicts is when I tried using a third party syncing program to sync to a folder that Seafile also synced. Had the same problem with Dropbox and Google Drive with a third party sync app.
Then don’t even bother resolving conflicts, because people should never make mistakes. It’d be great if seafile could wipe their computer if it finds a conflict, after all, there were doing something wrong.
The purpose how often it’s happening, because his solution is making it worse for most people.
A conflict actually is being resolved as long at is possible.
The main problem is office files (xls, doc) that stay open long time on many devices and can be often saved without any significant changes.
So in Seafile library I want to see only one fresh version, saved on any device.
And only if I got bad version of file in library, I can go to Seafile and view revisions, restore needed version.
But now I always see a lot of SFConflict files that must delete manually.
I provide to create this as special option in library, for only special use cases (like me), and not enabled by default.
MS Office does have ways of enabling co-authoring, but it requires using a share method of some kind. MS Office will allow co-authoring with Sharepoint or OneDrive, but the docs have to be shared in order to pull it off.
I had this same problem with Quickbooks a while back, and finally opted to save Quickbook files to a non-synced folder first. Upon exiting Quickbooks, it then saves a copy of the file into one of my Seafile sync folders.
However, as far as I know, MS Office does not have an auto-backup feature at logout.