So I’ve been using Syncthing for about 2 years now. I’m very comfortable with it, I know its quirks when it comes to case-(in)sensitivity. I have about 6 devices in my swarm.
I now have a node that has been down for two months that is a member of this swarm. I want to bring the node back into the swarm but I have some reservations/fears when doing so. Let me explain.
4 nodes up almost continuously, 5th node down for two months. Shared folder contains 5 files by now, the node that was down contains more than 5 files, namely, a couple of ones (let’s say 3 other files) that I deleted in the time that the node was down. I rejoin the node, only for this shared folder (all other folders are paused). To my dismay, I get the files “back”, i.e, instead of ending up with 5 files, I have 8 files now, which sugests to me that Syncthing does not “remember” deletions.
This is no problem for this particular folder, but it will be a problem for folders with 100000s of files (i.e, big number of files previously cleaned up or moved would be reintroduced by the node that was down for 2 months, causing massive amounts of double files or reintroduction of previously deleted files).
What to do here? I want to essentially tell this node: “whatever you think you have, you’re wrong, become like your brothers who were up for two months while you were down”.
Much kind regards + thanks in advance for any pointers here,
Saying what happened in retrospect is mostly impossible. Syncthing does remember deletions, they are recorded like any other change. What I suspect happened is that on the offline device, those files got modified (even if just bumped modtime) while it was offline. So when it came online that change was in conflict with the deletions on the other device. And for conflicts, deletions always loose.
Riight, so, in this case, this was a disc that needed to be replaced, so I set up new os, saved all syncthing config files, made backup to usb (same filesystem types, ntfs) using robocopy like this:
robocopy C:\Users\rubin\Syncthing\Documents U:\Syncthing\Documents /mir /b /xj /r:0
After recreation of new filesystems, I used the exact same command with the source and target reversed to restore. I expected the filedates to be preserved because of /mir and /b but it seems to be not the case, because that is the only reason I can see where syncthing would consider these files modified.
You didn’t explicitly mention the db: If you didn’t restore it, that would have also been a reason for that behaviour.
Robocopy does preserve file timestamps by default. Folder timestamps are not preserved, but that should not affect Syncthing. The
/b switch is for copying permission protected files, so it should not matter in this case.
set all folders on this node to receive only (and possibly hit the button to reverse local changes after everything synced)