knnknn

Killer bug: Newer files are overwritten by older files (dates months apart)

Recommended Posts

I have two PCs (Windows 7, clock up to date, NTFS, same folder structure).

Today I turned on PC#2 (after months) and removed a synced folder (right-click remove, key started with A...) and readded it (key starts now with D...).

The same folder on PC#1 was already a folder with key D..., running v2.6.0 (1312), PC#2 (the PC which was off for months) had still v2.5.12 (1191).

Resilio sync copied all older files (months apart) and overwrote the newer files.

The sync.log file (of the PC with the wrongly overwritten files) is full of wrong statements:

[2018-08-18 23:54:23.189] MC[290F] [FF25]: Local file aaa.txt is older than remote t:1534293927/1534625685 ot:1477197/101990 o:10A25E3D0A21D5655EC98C95FCB0F531F7876C32/103DAB3C217A3F67755C205E3C5E65E09F8BFF25

 

 

Share this post


Link to post
Share on other sites

From my experience, 2 mistakes here:

  1. If you disconnect a folder, be sure to delete everything from it before reconnecting. Reconnect and have Sync fill the folder from the other peers. Technically Sync should recognize pre-existing Sync folders, but I've noticed it doesn't reliably do so.
  2. Sync doesn't handle peers who've been offline for extended periods of time very well. That's one of the reasons I literally check my peer number when I wake up and when I get home from work, and immediately investigate when a peer goes offline, because otherwise I've run into trouble.

Share this post


Link to post
Share on other sites
On 8/24/2018 at 9:48 PM, jdrch said:

From my experience, 2 mistakes here:

  1. If you disconnect a folder, be sure to delete everything from it before reconnecting. Reconnect and have Sync fill the folder from the other peers. Technically Sync should recognize pre-existing Sync folders, but I've noticed it doesn't reliably do so.

This is true. However, it's one thing to mess up some syncing but another thing to overwrite younger files with older files, which should never ever happen.

Share this post


Link to post
Share on other sites

did you send the lgos to support? This case needs to be investigated until logs are rotated. Also, did you check "modified" timestamps on files? from the quoted line : 
local timestamp 1534293927 = Wed, 15 Aug 2018 00:45:27 GMT 
remote timestamp 1534625685  = Sat, 18 Aug 2018 20:54:45 GMT

so local file dated 15th is older than remote dated 18th. 

Share this post


Link to post
Share on other sites
16 hours ago, knnknn said:

This is true. However, it's one thing to mess up some syncing but another thing to overwrite younger files with older files, which should never ever happen.

You know, based on what @Helen just said I'm wondering how different peers agree on time. Do they use the clocks of the respective systems they're on, or ping a time server? Also, do they check down to the seconds, or only just minutes? I'm not sure if the behavior I observed previously has anything to do with this, but I think having a PC off for a while (or in some similar situation where it goes for a long period of time without syncing its clock with a time server) can cause clock drift. In one instance my Authy OTP codes were failing at login; I found out the reason was my PC was over 30 seconds off, causing the code it generated to be expired on the server side.

Just throwing this idea out there: in cases where Sync runs as a service with sufficient permissions, perhaps it should force a system time sync under certain conditions that are likely to result in old -> new overwrites. Of course, defining said conditions is another discussion.

Share this post


Link to post
Share on other sites

Sync takes local time and converts it to UTC taking  computer's timezone into account. So if time and time zone are set correctly on a computer, peers even on different continents will have same UTC time in the end. Sync allows up to 10 minutes of time difference between peers, and it knows about this time diff when comparing files

See this post 

 

 

Sync takes unix timestmaps, see above, to compare time. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now