SyncTrayzor conflict resolution went bad

Support
1

Hi. I have a SyncThing setup with several devices, some Linux, some Windows, some Android, all running up-to-date clients (syncthing-gtk on Linux, SyncTrayzor on Windows).

One of my Windows boxes was offline for a few days, and I brought it back on a new PC. I copied over the entire AppData\Local\SyncThing and AppData\Roaming\SyncTrayzor folders from the old PC to the new one, as well as the synced folders themselves, rather than adding the new PC as a new device and setting up all the folders from scratch and letting them copy across.

The problem started when SyncTrayzor on the new PC popped up a dialogue asking me to resolve some file conflicts. They seemed to be regarding files that were updated recently on a different device, i.e. during the time when the old PC went offline and the new one took its place. In each case in the SyncTrayzor dialogue I picked the file with the latest datestamp, as I assumed that would be correct. However, now I check each file they have gone back in time a few days. I think I am now left with the version that was on the PC storage before it went offline.

Any ideas how I can further diagnose or recover from this? All my devices have Staggered File Versioning, but looking in the .stversions folder on all devices, I’m not finding what should be the latest files, only the older ones. Is file versioning not used when dealing with conflicts?

I can post logs etc., but what I can’t provide is screenshots of the SyncTrayzor conflict dialogue.

2

I take it (partially) back. I have just found usable up-to-date backups in the .stversions folder on one of my Linux boxes.

I still can’t explain what went wrong in the first place, but don’t fancy trying to force recreate it.

3

I think you copied the files to the new computer without preserving the timestamps, so the old files where “newer”.

4

Well actually I just moved the old HDD to the new PC.

5

It’s possible that the database was newer than the files, in which case even files with an older timestamp can look like they are newer.

6

By default the Conflict Resolver tool puts the copies you don’t choose into the Recycle Bin, so you can get them back from there. (There’s a box you can uncheck to disable this, but it’s checked by default).

7

I think this is indeed just standard windows timestamp behaviour: I had the same recently: Conflict in which the actually more recent file had an older timestamp. Luckily I could see that from its contents. I have no idea why and how it happened, and I don’t have any interest in investigating windoof behaviour. For me the message was just to never rely on timestamps on windows regarding sync conflicts.

8

Ah yes, so it does. I never usually use the Recycle Bin so I didn’t look in there. That makes recovery much more simple, thanks.

9

I tried to make it fairly obvious that that’s what the conflict resolver would do. Suggestions to make it more clear welcome!

10

Thanks for the screenshot. I think part of my problem was that I just clicked through it quickly, without properly looking at it, so I didn’t notice the Recycle Bin thing. Maybe where it says “The other versions will be deleted”, the word “deleted” could be a drop-down with a choice of “deleted” and “moved to the Recycle Bin”, instead of the tick box at the bottom, going by the theory that people take more notice of things at the tops of windows rather than the bottom.

Regarding what I did, I just looked in the date column and clicked Choose on the most recent named file each time. I didn’t even notice that one of the headings was “Last Modified” and “Conflict Created”. But I’m sure for each file (there were about a dozen of them) I carefully picked the one with the most recent date. So I guess the question is why did the “wrong” file have a more recent date in that dialogue. It’s quite possible we’ll never know.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.