I am debugging a case where
- for some reason a local Seafile Insance stopped working (“bad index file sha1 signature”)
- in the meantime the remote received updates by someone else
- I desync/resync the library and let Seafile “fix itself”
What should I expect of this “fix”, if during the connection drop,
both endpoints received updates to the same file?
How does Seafile handle this?
Will there be a SFConflict file or not?
I just tried to reproduce the situation you described. On my laptop I un-synced a library. I deleted a couple of files from it and modified a few. Then I modified some of the same files on my desktop, but modified in a different way. Then I synced that library with the same directory again on my laptop. The files I deleted from the laptop were replaced with versions from the server, and the files with conflicting changes made the SFConflict files.
What surprised me a little is that files that had only been edited on the laptop became SFConflict files too. I guess it didn’t have a way to know when the copies diverged (or even that they had, maybe they just have the same name by coincidence but are completely different). So it makes sense, I just didn’t think it through enough until I had to to explain what I saw.
So the rule seems to be, when syncing an existing folder it is made to match the server. If the files already there don’t match the server, then the server’s version “wins” and the existing versions become conflicts. And files that only existed on one side get copied too the other.
Hey thank you very much for your effort.
So it seems it cannot know “deleted” therefor produces new. I guess no whay around that other than monitoring locally and respecting what is learned therein (knowledge which is broken anyways if i unsync).
“only 1 client edited, therefore error” makes sense because it would compare against the server-only anyways even if multi users are involved?
I am really relieved there seems to be no predefined winner upon “file exists”.
So remaining question is: does it do this by date/timestamp only or does it size or checksumming too?
I guess this would be for the devs.
I’d be glad to know it wasn’t just timestamps.
But how to handle this danger best-practise?
I had setup a client headless on a samba server, and since such lockups seem to occur from time to time, even (and often) with a complete seaf-cli stop, and there is no history in such a reconstruction, there should be some kind of alert system if it goes wrong. with a team of people just one day of messup can easily jeopardize people’s nerves. I wonder how I should set this up. How/where would we best hook up a mail command for example? … I wonder. …
maybe someone has an opinion what interface is most stable to do this.
can a dev comment on these question too please? thanks.