What determines if a sync deletes or replaces

Recommended Posts

W7 x64, 1.1.69 / 70, all pointing to the same time server.


This morning I watched a laptop remove 4 folders off the server for no apparent reason. The history says it was remote peer and the users laptop name, which was actually the same device. As yet I am unable to figure out the reason why since the owner would of had no reason to have deleted these files (and he says he didn't), but also it's the same 4 folders that regularly seem to just disappear, but it got me thinking about folders in the future.


So lets say there is laptop A and server B


A and B are synced 100%, so A has 20 files, B has 20 files

A is off the internet, B has 10 files removed

A gets back on the internet and see 10 files are missing. What detemines if it removes the same files on device A or replaces the missing files on device B

What if laptop C is then added to the same secret, it's got 0 files so whats from stopping C removing files and foldes from A and B so that A and B are in 100% sync with C


A few weeks ago we swapped a server* at a customers and I had a secret running on a folder prior to the installation so their shared folder was already synced. However because there were 2 remote laptops that were disconnected at the time that the server was replaced these caused a lot of folder to be removed (again, no logical reason why). In the end we had to sync 17Gb from 0 on a new secret to ensure nothing was missed, but we / they are still getting files that are doing odd things because they are not connected 100% of the time.


I fear this question /faq has been covered before, but as the forum is just back up and I could do with knowing as they are asking for answers other than 'its in development'






* we know it's beta and run hourly snapshots until the software is RC but the benefits are worth the pain.


ps, I forgot to add, the computer that removed the files from the server didn't have the missing files in their recycle bin, but they were in syncarchive which means that another device deleted then, but if thats the case, why didn't the other device remove them off the server since the server is on all the time but the laptops only appear during working hours.

Link to post
Share on other sites

I know you say all your devices have the correct time and are sync'd to the same time server, but it'd be worth checking the actual time stamps on the files in question themselves to ensure they're valid (i.e. not set to 1 Jan 1970, or some arbitrary date/time in the future).


If files were created/modified at a time when a system clock was previously incorrect, even if you then subsequently correct the system clock, the affected files will still remain with invalid created/modified timestamps from when the system clock was wrong... worth checking/ruling out at least!?

Link to post
Share on other sites

I have managed to find the user but not verified their clock (which again, shoud be syncing to the same time server). As for the files, all the laptops had to be resynced to a fresh folder with a new secret when the server was installed so in theory they should have exactly the same files as the server.


I had a report of a newer file replacing an older one, essentially the one modified on the afternoon of the 8th was replaced with the one that was there previously.


There's a lot of entries around the same time / folder but essentially they say..


[2013-10-08 18:47:07] Merge: Local file Suppliers & Sub-Contractors\XXXXXfolder\YYYYYLoads2011.xls is older (1381245473) than remote (1381254308)


But why would the remote file show it's older when it's been untouched? Does BTSync look at the date modified or access attributes? i'm wondering if something as innocent as a anti virus scan could be fooling bts into thinking that local file is now newer than the server file?


I have attached a new screen dump, if you look at the snapshot times and days you can see the original file at the top, modified during the day, but then it had reverted back by this morning (bottom one)




Link to post
Share on other sites
Does BTSync look at the date modified or access attributes? i'm wondering if something as innocent as a anti virus scan could be fooling bts into thinking that local file is now newer than the server file?


Sync looks at the size of the file as well as its last modified date (or if no modified date is found, its creation date)


An anti-virus scanner shouldn't be changing the modified date of files it scans, unless of course it detects a virus and attempts to "clean" the file

Link to post
Share on other sites

I managed to get on the query laptop that has been deleting files. Comparing the file (the one in the screen dump) the only difference between the file was the server one was created on 8 oct and the laptop one was created 1st oct. Therefore since the date modified was the same, and the file size was the same why did sync decide to overwrite the server version which was created a week later?


It's very puzzling. clearly something is wrong somewhere in the way it's comparing the files

Link to post
Share on other sites

Can you advise me if this statement is still true..


"But be aware that BTSync will not compare file dates to establish who has the newest version of a file - it compares the "file added to BTSync" timestamps instead. So you could end up overwriting new with old versions."


(23520-how-to-sync-with-a-pre-seeded-directory/ thread #5)


This does seem to be closer to the errors I am seeing

Link to post
Share on other sites
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.