Old Files Being Sync'd Over New Ones

[Nairou]

I have two (Linux) computers, which sync a folder containing text files. Whichever computer I happen to be using, that's the one I edit the files from, knowing that btsync will keep the two computers updated.

 

However, I've noticed several cases where newer changes on one computer get replaced by older changes from the other computer.

 

Example scenario:

• One of the computers (desktop) is always on, and the other (laptop) gets turned off when not in use.
• I am using the laptop, and edit some files. Everything is fine, the desktop gets the changes.
• I shutdown the laptop for the day, and later make changes on the desktop. The files on the desktop are now newer than the files on the (powered off) laptop.
• The next day I power on the laptop. The changes made on the desktop are not visible, the files are the same as when I last used the laptop.
• If I now check the desktop, I find that the latest changes made on the desktop have been replaced by the (older) copy from the laptop.

What would cause this to occur? How does btsync determine which one os newer? The date/time is correct on both computers, so that shouldn't be it.

 

For reference, both computers are running version 1.3.109.

[JimmyTheSaint]

I've always had that problem with my Linux boxes (I used to run two, but now it's one): any changes made while the Linux btsync process isn't running get clobbered as soon as I run it again. Since both of mine are NAS's, they're up 24/7, so I've only encountered the problem on occasion. But if one of my Linux boxes gets hit by a power failure that overwhelms its UPS, or if I don't ensure that everything else is idle while I do a system update, then I get hit. My biggest nightmare is if a Linux box goes down or I forget to manually launch its btsync process for a few days--then I know I'm in for a lengthy restoration session (or must re-sync from scratch). But the pain has taught me to always remember to manually launch the btsync process after a reboot, and a system crash is unlikely to escape my detection for very long.

 

In your case, you have a Linux laptop, and so you have a reason to shut it down or suspend it. My NAS's are designed to be up 24/7, so I'm not in your situation. But if I installed Linux on a laptop, I would expect to have the problem you describe based on my Linux NAS experience. No clue how to fix it, but a dev will likely ask you for logs to help you troubleshoot. It would be wonderful if you could help out that way because I'm currently not set up to do that anymore. I shut down btsync on my other NAS to avoid possible problems at work.

[ByteHeaven]

I have this same problem with windows machines too. Just recovered files from .syncarchive while putting laptop on replaced older files over newer ones. I do not even use android client because of this problem (it always replaces old versions while putting it on).

 

So I have NAS (always on), 3 windows computers. For example now: I had had laptop off for a while, had edited files on both desktops (home and work) and syncing went just fine. Now I put laptop (windows 7) on, it updated torrent sync version and updated those older versions from it over the newer ones... I really hope this versioning is fixed soon, it can cause a lot of trouble..

[JimmyTheSaint]

So I have NAS (always on), 3 windows computers. .

So I guess those are Linux NAS's? In that case, the 1.4 old-overwrites-new problem seems to be related to Linux or running Linux and Windows clients at the same time. I mean, we don't see other people reporting old-overwrites-new. As I mentioned, I'd like to try a clean re-install/re-sync on all devices at the same time, but I don't know when I'll have time for that.

[ByteHeaven]

Ok, but weird thing is, that like in this case now:

- Windows laptop overwrote older versions to other clients

 

Just to let you know the details:

My NAS is Buffalo Linksys Quad Pro and I rooted it and installed torrent sync to it. It works just fine otherwise that if some other client is ofline a while, when it comes back online the device coming back to online overwrites files with the version it has.

 

On the NAS: Version 1.1.82 ( up to date ) is the version of BTSync.

 

Hmm.. I'm going to try (after all is now synced ok) following to avoid the problem (if NAS is causing it, following this thread to see if there will become solution) that I change NAS to be readonly client (thus, just making backup to it, not changing files on it..). Hope it is a fast fix to this.

[Harold Feit]

Version 1.1.82 ( up to date )

Not actually up to date unfortunately. Current is 1.3.109.

[ByteHeaven]

Hmm, so it did not autoupdate? Have to manually do that then..

[Harold Feit]

Across major versions, we have rarely done autoupdates because of compatibility breaking.

1.3.109 and 1.4.72 are the two current versions.

[ByteHeaven]

Ok manually checking and updating now versions + changing my NAS to be readonly sync, let's see if problems will be fixed. Thx. (point for having NAS in syncs is to have RAID5 secured backup + I backup that RAID time to time to my bitcasa account manually -> thus making sure I have a backup if something goes wrong )

[fergus4]

I just lost weeks of work thanks to this bug!

I am using 3 window machines (xp, 7 and 8.1). The xp machine is a server and on all the time. Windows 7 machine is basically on all the time too and windows 8 machine is a laptop that is shut down or suspended a few time a day. Most file edits is done on the laptop with some on the win 7 machine. All bitsync clients are up to date but the over writes may have been on the last version.

 

I do not know what to do as this has set me back pretty far. Is there anyway to recover these newer files. They do not exist in the .SyncArchive of any machine. 

 

Also, can I trust Bitsync anymore. I had lost some stuff before but not to this extent...I AM SICK TO MY STOMACH!!!

 

I have my wife's office set up using BitSync and those are legal documents....Do I need to find an alternative?

[JimmyTheSaint]

They do not exist in the .SyncArchive of any machine.

I've gone through several recovery sessions in the past year. It's tedious, but I've always recovered everything using the history tab and the .SyncArchive folder. Does history reveal what happened? If the stuff's not in .SyncArchive, then I don't know what you can do. Stuff might get permanently lost once when you update to a new version, I'm not sure. I've learned to monitor history occasionally, even when I don't suspect any problems.

[Nairou]

I'm starting to get a feel for what might be the problem here.

 

The problem only ever seems to occur when I make a change to files on my laptop, which btsync will want to sync, but then very shortly afterwards shut off or suspend the laptop. It's as if btsync creates a list of files that were updated, files it thinks it now has the newest version of, in preparation to update other computers. The update occurs, the other machines download the files, but before btsync can confirm that everything is synchronized completely, it gets cut off by the shutdown or suspend. Then, next time the laptop is powered on, that list still exists, and btsync attempts to continue by broadcasting the files as new updates again. Files which are now out of date.

 

Ideally, btsync shouldn't persist that list (assuming that's what is actually happening). On startup it should scrap any activities it was in the middle of and start fresh.

 

But barring that, I've had some success by waiting a few minutes between the last file change I make and when I shut off the laptop. I also moved btsync startup so it is launched by a system service, rather than launched by X, so that during shutdown it isn't abruptly killed by X closing, giving it a bit more time to clean up.

[GreatMarko]

To confirm, are you seeing this behavior in the latest 1.4 build (1.4.103)? This build "Fixed issue with older files replacing newer files in some cases"

[Nairou]

Interesting, I didn't know about that fix. Up until last night, my laptop was still running 1.3, so I'll have to see how it goes from here on out. Thanks.