Newer Files Overwritten By Older Files - Btsync 1.3.94


Recommended Posts

Let me first say I've been using BT from the start and on a lot of devices for a number of reasons and have yet to encounter many issues (aside from some stray !sync that linger, only around EXCEL files for some odd reason, those just randomly will not go away). 

 

Now to my current and FIRST real issue.

 

Two machines. Both running BTS 1.3.94. Windows 7. 32bit.

 

Machine "B" went offline for about a week. I fired it back up. When I noticed it was off (this is the only thing this machine does), not part of the issue.  BTsync launched fine.

 

This is a Monday. Machine "A" was always on and continues to be the main source of files and edits. So Machine "A" edited files all week.

 

About Thursday I saw machine "B" had a "BT Sync STOPPED working" windows type error dialog. I clicked OK on that. And restarted BT Sync. Checked, it was running and looked like it was syncing once again.

 

So the following day. Machine "A" files were reverted back to Monday. Nearly every one of them, file date time stamp all back to Monday. So we lost all the edits and data entry that was done to those files on machine "A" during the week.

 

I know files were edited and should have synced UP to "B" but instead, came DOWN to "A" when they clearly were older files. 

 

I was able (thanks to scratch files exel leaves behind) to recover all the data entry that was lost. It took some effort but totally worth the time given the amount of work it would take to recreate.

 

I am only guessing it was associated with the BT Sync STOPPED windows error message and me restarting it that caused this but is there any way to know what caused this? And what should I do if this happens again? If I see that again, I'm truly not sure what to do other than uninstall and recreate the sync pair on the "B" machine as I don't want to just launch it again and have this happen again. 

 

I feel like I dodged a bullet.

 

I'm thinking of just recreating the folders as "read only" (since this particular setup is only about backup but not all my setups are just about that) but since it did take some effort to recover and this is the simplest of setups and we lost data. (no question BT overwrote the data) , I thought it critical enough to post this. 

 

My guess is that late in the day or night on Monday, machine "B" had that error (the reason files went abck to that date/time once I restarted "B")  I never looked at the machine again until I saw the error on Thursday. CLICKING OK and restarting BT Sync. Its almost liek it picked right back up where it left off, no matter how much time had passed since the Q was created perhaps? That's a guess on my part. 

 

thanks for the time and all the work on a great tool just the same!

 

-=darren

Link to comment
Share on other sites

I don't know why this happens, but I've learned to anticipate it and brace myself. On my Linux boxes (but, so far, not Windows or Android) if the btsync process exits in an ungraceful or unexpected way (such as a power outage), but also when I do "kill" on the process to do a system upgrade and reboot, that device will (sometimes? every time?--not sure) return to clobber any changes made while it was down. My biggest nightmare is when I forget to manually restart btsync so that the device goes days without re-syncing so that many files are involved. I've learned to stop forgetting due to the negative reinforcement. The clobbering will occur several minutes after restarting btsync, so I always sit and monitor the history window for the bad news. But I first make copies of the stuff I know has changed, sometimes rather large folders, and when I see that a few files got hit, I just delete entire folders, wait for the deletion to sync, and then restore from the copies. Otherwise, I'm in for a painful restore session.

 

For me, the key is paranoia: once I realize something unseemly has occurred, I stop doing everything, make copies, restart, then watch the history window like it's the Game of Thrones finale. When I do system upgrades, I make sure everything's synced first and then touch no files on any device until the upgrade's complete and everything's in sync again--this preventive measure has always been 100% effective. Yes, it's work, but the software is still considered beta, so we really can't complain that it's not yet down to a no-brainer. For me, it's been strictly a Linux issue; Windows updates have never been a problem, and I flash ROM upgrades on my phones every day from CM's nightlies.

Link to comment
Share on other sites

@simondarren

 

Some short question:

 

This is a Monday. Machine "A" was always on and continues to be the main source of files and edits. So Machine "A" edited files all week.

 

About Thursday I saw machine "B" had a "BT Sync STOPPED working" windows type error dialog. I clicked OK on that. And restarted BT Sync. Checked, it was running and looked like it was syncing once again.

 

So the following day. Machine "A" files were reverted back to Monday. Nearly every one of them, file date time stamp all back to Monday. So we lost all the edits and data entry that was done to those files on machine "A" during the week.

 

I know files were edited and should have synced UP to "B" but instead, came DOWN to "A" when they clearly were older files.

 

Do you know if files on machine B were changed / modified after "BTSync Stopped working"?

Link to comment
Share on other sites

They were not changed on "B". 

 

No one has access to it but myself. I didn't touch that computer from Monday until maybe Thursday morning when I saw the error. 

 

And what was over written by older files, were daily log spreadsheets and items that staff uses on "A" daily. So random and spread out, its not likely I would have even know to open each of those on this end.

 

And I wasn't sure if this was clear but it was EVERY file they changed on the "A" side after Monday. 

 

I thought about maybe a random disc error on the "B" side could have maybe triggered one file to change and cause something odd? 

 

If that makes sense. 

 

And new files created on "A" found their way back up to "B" fine. 

 

Which is why I was guessing its some type of Q issue on the "B" side. Tho I would have expected conflict resolution to kick in and COPIES created, not an overwrite. 

 

Not sure if that is helpful at all and it might be...expected. 


JTS, this setup is really basic. And given I'd had this setup nearly since BTS release and its worked flawlessly, I thought maybe a bug has crept in via a recent release so this post is almost more about feedback than it is resolution. Tho I'd like some advice if I see that BT STOPPED working message again b/c I'm for sure not going to just close it and restart BTsync. If I do see it again. I think I'll recreate the sync as read only so B side has no chance to change "A", which solves my issue but possibly not what could be a larger issue and I'll for sure come back and update this if that happens. ~thanks

Link to comment
Share on other sites

JimmyTheSaint -  Sorry, I thought I replied to you but thank you for your very insightful response. Most of my post here is about feedback. In case a bug has crept in. Since its all worked very flawlessly up until now. If perhaps someone had an idea what to do if I saw this error dialog show up again, that would be welcome, otherwise I think I'll just recreate my folders 'read only' and my problem goes away. But I thought I'd contribute my experience in hopes of some helpful feedback for product development. I appreciate your insights! -=darren

Link to comment
Share on other sites

@simondarren,

Thanks for the information. My first guess was that files on B were touched / changed while BTSync is off. In this case BTsync will think they are the most fresh once it starts again. However this is not your case.

By some reason Sync decided that files on B are newer and took decision to sync them back to A. I would like to find out why.

I wonder if you can turn on debug logging on both A and B and set log_size advanced preference to 200? In this case we will have a good chance to capture this event in debug log if it happens again.

Link to comment
Share on other sites

I have exactly the same issue. Newer files was replaced by older ones.

 

I edited the photos, there were around 300, I spent over about 3 hours.

At night, ran a full sync, a total of about 4 Gig of data.

Unfortunately the opposite direction.

All of my edited photos was again overwritten by originals.

 

I do not have detailed debug log, of course, but from the History there is clearly visible, that sync was running in opposite direction.


It seeams to me that the bug is stil there.

 


From the event log of remote side is visible, that the server was restarted during the night.

I'm quite sure, that the error appear after the reboot. The remote side was thinking that is most recent one and overwrite all of my edited photos.

 

Hmmm.

:-(


 

"Master" (where was edited, most recent photos) is running on WD NAS - PPC version.

"Remote" (where was old originals) is running on W2k8R2 server.

Using latest version of BTSync 1.3.106
Link to comment
Share on other sites

These people are not crazy, this happens to me too. Sometimes newly created files are deleted, sometimes they are overwritten by older versions from the other host.

 

I just turned on debug logging and tried in various ways to reproduce it, but was unsuccessful -- it definitely doesn't happen with all files in all situations. Yet it happened "naturally" yesterday with an office document that I created which, by the next morning, btsync had deleted.

 

There are only two computers in my network and the clocks are well synchronized. In my case btsync was running on both computers when the problem occurred. It was busy synchronizing a large number of other files at the time I created the document that was deleted.

Link to comment
Share on other sites

@kratochviljan

 

Was BTSync running on both peers when you edited files?

 
Yes, it was running on both sides.
 
I edited photos directly in directory which was synchronized in real time, I mean when I edited photos - under my hands and it works well. (there is one another issue with file locks - file which is synchronized by btsync is locked for writing so this can not be saved / modified during sync)
 
But due to the speed of my DSL line I finish all of my work on photos and btsync was still running. I thing it could run for couple of hours.
 
In this time period remote server has been restarted and after the reboot btsync start to synchronize all files from this directory in opposite way. So some photos remain untouched - those that was synced before remote side reboot, but most of them was unfortunately overwritten.
 
I'm 100% sure that there is no problem with different time on both sides, both are synchronized according to NTP server.
 
I think that this scenario could be easily reproduced if you have some testing / lab environment. Eventually I can try to do myself if I find couple of hours for testing on this, but seems to me that could be done easily on your side - you will to know much better where to look and for what.
 
Regards,
Jan
Link to comment
Share on other sites

@kratochviljan

 

Unfortunately the issue you are facing is not that easy to reproduce in the lab. It is extremely sporadic, but you've gave an interesting hint - a server reboot during Sync. Was remote peer restarted legitimately or it crashed?

 

@mould

Yep, debug logs are helping greatly in catching such sort of issues. You can also set "log_size" advanced preference to, say 100 (which means 100 Mb) to have more chances to get the issue recorded in debug log. Also note, that it is very important information which applications you were using when issue happened - all apps are working with files differently.

Link to comment
Share on other sites

I just had a similar problem which cost me many many hours of work to fix:

 

Machine A) MacBook with BT Sync 1.3.94. Here I worked with Lightroom, modifying my 5 GB Lightroom database.

 

Machine B) Synology NAS with BT Sync 1.3.94. Here I used the readonly key to make backups from machine A.

 

This config was running for a while without problems.

 

Now the sync was interrupted (A was in standby over night) and left a .!sync on B instead of the original lightroom catalog.

When the sync resumed (probably after a shut down and reboot of B over night), the unimaginable happened: the new lightroom catalog file on A was deleted (ignoring the read only key!) and replaced with a .!sync file, which of course was incomplete and corrupt.

 

Unfortunately my second backup (Crashplan) didn't had enough time to backup the new lightroom catalog before BT Sync deleted it. So all my edits were gone.....

Link to comment
Share on other sites

@all

We are still trying to repro this one in he lab. 

 

@mariano

If this is reproduced regularly on your PC, I'd ask you to collect some debugs. Here are steps:

1. Turn on debug logging on both PCs affected.

2. Make sure your "log_size" advanced preference is set to, say 200 (which allows BTSync to store 200Mb of logs), also both PCs.

3. Work as usual.

4. When you noticed that "old version returned" - mark down the time when it happened and proceed to step #5.

5. Collect debug logs (sync.log, sync.log.old) from both computers.

6. Mail logs to me, also let me know the filename which was rolled back as well as which computer supposed to have the newer version.

Thanks!

 

@WeeGee

This is pretty surprising by several reasons:

- All the files are signed with digital signature before they are sent. Private key is owned by RW peers, while RO own only public key. So, RO peers may only receive files - and none of RW peers will accept modified files from RO as they are not signed.

- .!sync files are ignored and never synced as they are service BTSync files.

 

So I suspect that you have yet another RW peer, that decided to sync your Lightroom database. Are you confident that you have only 2 peers? You can check this in the "Devices" tab to see which peers are online.

Also, did you check that deleted database was moved to .SyncArchive folder?

Link to comment
Share on other sites

@mariano, yes mine were ALL XLS files as well and I'm pretty sure other file types were modified during the down time and yet, they were not reverted like the XLS files were. least not reported to me.

 

@weegee, YIPES! Sorry to hear even with readonly enabled. That was my backup plan. I would have tried some FileSystem undelete tools myself on this one. 

 

Update on me: 

BTSYNC crashed again. I've not restarted it. Backing up on both ends first. Will restart and get back if we have another incident. 

Link to comment
Share on other sites

@mariano

If this is reproduced regularly on your PC, I'd ask you to collect some debugs. Here are steps:

1. Turn on debug logging on both PCs affected.

2. Make sure your "log_size" advanced preference is set to, say 200 (which allows BTSync to store 200Mb of logs), also both PCs.

3. Work as usual.

4. When you noticed that "old version returned" - mark down the time when it happened and proceed to step #5.

5. Collect debug logs (sync.log, sync.log.old) from both computers.

6. Mail logs to me, also let me know the filename which was rolled back as well as which computer supposed to have the newer version.

Thanks!

Sorry, I'm a little busy ... I'll send the email as soon as I can!
Link to comment
Share on other sites

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.

Guest
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.