If a file is removed on a peer, the deletion of the file should always take precedence over getting the file synced back again.
When I deleted a file on a peer 1 while peer 2 is disconnected, then the file (sometimes) gets brought back to peer 2 when it reconnects. I don’t exactly understand the mechanism when syncthing decides to bring back the file, or remove it.
The file will be revived if it’s (considered to have been) changed on peer 2 in the meantime. I added the parenthesis because Syncthing takes a very pedantic view on what “changed” means, so touching any bit of the metadata will count.
This is generally the safer approach. You apparently want the opposite in this case, but we get more people with pitchforks in the forum when files are deleted accidentally than when they are not. So the flippant response to the topic title “file deletion should always take precedence” is “no”.
I appreciate the explanation. In case the deleted files get brought back, is there at least a way to see which deleted files got brought back so I can delete them again?
Unfortunately I don’t think there’s a simple way to do that. (I can’t think if a hard one either off-hand but it’s probably possible to deduce from debug logs somehow.)
Depending on why the files get resurrected you might be able to mitigate on the peer-2 side by setting a modtime window, ignoring permissions, or otherwise figuring out what the change – real or imagined – seems to be.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.