Is it possible that Syncthing might think that the folder is deleted when a mount is not mounted therefor asks the other side to delete the whole content of the corresponding sync node? I feel like that is what happened to me. I just saw that one of the node (in 2 node setup) deleted everything in the sync folder. I think that I started St before mounting my drive (using curlfs to mount ftp) so the folder exists but it was not pointing to a mount then. Then I realized that I did not have the mount so mounted it and restart St, but did not realize what happen until today, I was not checking and since then I did not do any sync.
Anyway not saying that this si what happened but is it possible that unmounted folder might confuse ST?
Yeah, if the folder unmounts half way through the run, syncthing will assume everything is deleted.
Well it was not halfway through, it was that the mount was not mounted when St was run. In anycase even if it is unmounted halfway through, should not it be more careful about it? I mean that does not sound right to me as a user.
Would not it make sense if ST has some kind of id file in ever folder to make sure that the folder is syncable or not (ie missing id file means something went wrong with the file system)?
It does have that, we just don’t check for that after starting sadly. I am sure there is a bug for this in the tracker.
How does rsync behave if you run it with --delete and umount half way through?
not sure if comparing different type of applications is useful in this case.
Let me put it this way. Lets say that you use ST for backing up between 2 nodes. The harddrive that your share is on fails on one of the nodes in the middle of the sync, and St also deletes the files on the other side because it thinks the user went away and wiped the whole sync folder. Now the whole idea of using ST as backup tool is abit borked in this case. This kind of stuff happens all the time that is why asking for better sync integrity.
First of all, don’t. Syncthing is a sync solution, not a backup solution. The use cases are similar but have different corner cases, as you’ve discovered.
We currently do check that the sync directory exists before each scan. If it doesn’t, we assume something bad happened and abort rather than classify everything as deleted. We could do slightly better here though. Here’s one relevant ticket:
This is what Unison says when all the files are wiped.