Syncthing overwrote files with very old versions

I have 4 devices running Syncthing 0.11.2. 3 devices are used most days of the week and have been syncing just fine for many months. 1 device acts as the central server (VPS), the other devices only connect to that server.

I also have a Windows 8.1 computer that I only boot once a month or so. Today I booted it up, upgraded it to 0.11.2 (it was still running 0.10 so could not connect to the 0.11 server) and it started syncing. Then this evening I noticed on my Ubuntu pc that many files had been overwritten with very old versions, which of course were the outdated files coming from the Windows 8.1 device.

What could have caused this? How to prevent this?

Fortunately the 4th device has not been online yet, so I can boot up that one (without wifi connected) to make a backup of the most recent files. How can I trick Syncthing into believing afterwards that those files are the newest and should be distributed to the VPS and therefore to the other devices as well?

If the files are different on initial index (as in the upgrade v0.10 -> v0.11) one file will “win” and the other be archived as a conflict - did this not happen? I.e. you didn’t get somefile.sync-conflict-20150501-121212.ext and so on for the overwritten files? Them getting overwritten with some other version after upgrade and there not being a conflict sounds very bad and weird indeed.

Thanks Jakob, I indeed see many ‘confict’ files fortunately. I will keep in mind to boot and sync the Windows-pc before upgrading devices to a future Syncthing release which requires a new initial index.

What caused the much older files to ‘win’?

The first 63 bits of the device id, aka randomness, which all devices agree to follow.

Wouldn’t it be possible to look at file modification time or something?

No, because it does not mean that the modification time is accurate.

You can read about lamport clocks and vector clocks if you wish to understand why trusting time is a bad idea and the problem as a whole better.

In general, it’s not that much of a big deal, whats most important that the conflict is detected, in which case no damage is done.

Edit: now that I think about it, it might make sense, though all the papers suggest to forget about time, hence perhaps there is more than meets the eye.

I can imagine the possible problems. But when it is very clear that one file is much older (in my case several weeks) than the other one, I’d expect the newer to ‘win’.

But indeed, glad to see the conflict was detected and a copy of the file was made before it got overwritten.