Help: Newer files overwritten by older files

[BeTheSync]

I'll try to tell, what I discovered the last months and hopefully adding usefull information to this thread. When I have more time, I'll try to add some logs too, if I got THIS resolved.

Prefs:

-1.1.48 on WinPC/Linux/Mac

-Full acces secrets on all shares

-A WinPC is the origin source of the files (source of the used secrets) and Linux/Mac are the peers.

-WinPC shares 20 folders to Linux Server

-Mac shares 11 folders to Linux Server

-Linux Server shares nothing itself, but should act as an ever-reachable datasource, if I need access to some data, or like to add some data to the Mac or WinPC if I'm not in front of them.

Recognized:

-Overwritten files which are not locked by a process.

-The overwritten files are (sometimes) found in the .SyncArchive folder on my WinPC, where they are overwritten.

-Overwriting happens, when all btsyncs are running over some days, or if one of the btsync is restarted. When I restart the Linux-btsync, I can reproduce this faster.

-If a newer file is overwritten, I can just change it again and it will then be overwritten again and again and again, if I repeat changing it. It stops after some manual changes to the file, then it seems, that btsync has accepted my choice :-)

Done:

-Systemclocks on all devices get their time from the same timeserver. They're (almost) identical.

-.!Sync, .SyncTemp, or .SyncPart files are deleted on WinPC/Linux/Mac and btsync is restarted too

Apparently, the issue seems to only happen for "some" files.

Example1:

On WinPC (folder sync only to Linux)

An XML file, which is changed by a opened program gets overwritten after closing the program.

Btsync overwrites the changes back from the old file stored on the Linux server

Example2:

On the Mac (folder syncs only to Linux)

An opened and changed XLS file (as described some posts earlier) was overwritten by the Linux btsync.

Example3:

On WinPC (folder syncs to Mac *and* to Linux)

I change an existing textfile in Notepad++, save it, and btsync on WinPC syncs it to the Mac and Linux. Everything (seems to be) ok.

settings on Linux:

settings on WinPC:

Settings on Mac:

[BeTheSync]

But you already had a backup, right n_u? Not having a backup when you're using alpha software, well that wouldn't be a good idea.

Hi, this post is not old, so I assume, you use a newer version of btsync?

Mine is 1.1.48 and I cannot see an apha-status in the Software.

Not with btsync --help on Linux, nor anywhere on the Windows or Mac Windows

Also, I guessed with a mainversionnumber >1 the alpha status is not anymore.

But, as far I see and critical bugs/errors occour like the one in this thread, it could be alpha software.

So can anybody please state out, if this software is downloadabe as alpha or stable?

[hitchhiker]

Is there any news on this, i'm seeing it happen on 1.1.82 between win 7 / mac

[BeTheSync]

nope. same thing.

btsync deletes files which are newer.

i'm seeing this since two weeks, since i gave btync a second chance after a long time.

[Harold Feit]

Current is 1.2.73 not 1.1.82, please update and report again

http://forum.bittorrent.com/topic/24781-

[BeTheSync]

WebGUI says: "Version 1.2.72 ( up to date )"

Windows says: "1.1.82"

Mac says: "1.1.82 (1.1.82)"

 

Also it produces tons of 2013-08-29 07.49.43.jpg.!sync (Photos from Camera) files with the size of the original image, but filled with zero-bytes....

 

but thats another (very very bad) issue...

[Harold Feit]

Current is 1.2.73 not 1.1.82, please update and report again

http://forum.bittorrent.com/topic/24781-

[BeTheSync]

Thank you for clarification!

I relied on the autoupdate-feature on mac/win *and* on the "up to date" message from the linux webGUI. (Also "Check for newer Versions" said the software was up to date on win/mac)

 

Computer generated messages are not dependable at all, it seems.

 

Have updated all three devices and will check again...

Current is 1.2.73 please update

 

[ragnarok]

Just had this same issue on two of my computers running BTSync v1.4.103. Lost a week's worth of work. This is a deal-breaker. Really needs to be fixed ASAP.

[nrgbod]

I'm getting the same problem on v1.4.103  win8.1 & raspberry pi  and android.

[GreatMarko]

@ragnarok / @nrgbod - 1.4.103 has since been superseded by 1.4.110. Do you still experience your issues when running this latest build?

[GieltjE]

@ragnarok / @nrgbod - 1.4.103 has since been superseded by 1.4.110. Do you still experience your issues when running this latest build?

 

I had this problem with 1.4.110 where a read only client (backup only) forced the whole collection back a few days after it had been offline. (in this case a quite severe error as this involved our git server!)

 

The backup server is a raspberry pi running Raspbian and the master server is a Server 2012 running in VMware.

[EscapeArtist]

Basically, I believe that BitTorrent Sync can never be a valid personal cloud service unless a 100% reliable machine, always on, is linked for every shared file. As a result of not having a reliable "server", I regularly get older file versions as a nasty surprise. If you can't rely 100% on one of your syncing machines always being up, you must check every time you save a file that it is actually syncing somewhere.

 

I feel I have to repeat that: You either must have an EXTREMELY reliable machine that is always on, or you must check every time you change a file to know if it propagated (and remember if there are lots of files which did and which didn't).

 

Otherwise (this is obvious, but I will lay it out anyway):

 

- Three machines, A, B and C are supposed to sync a file, let's call it temp.txt

- Machine, B,  is supposed to be the "server" (i.e. always on)

- B is down for whatever reason, C is typically down, so only A is operational 

- This "should" never happen, but of course, always will at the worst time possible

- A changes temp.txt 

- A is shut down assuming wrongly that the temp.txt has been synced to B

- B is now turned on again

- C is turned on and temp.txt is modified there assuming it received the latest version from B

- C syncs the mixed version to B

- A is turned back on and receives the mixed version from B

- A's original mods are lost

 

This has happened to me MANY times.  I am looking at creating a droplet at Digital Ocean to try to get something more reliable as a "server", but there doesn't seem any other solution. 

 

It seems to me that BitTorrent Sync could "know" that A never synced the file after it was modified. Knowing that A's version of the file is "hot" and needs to be synced, it could warn when receiving the file from B.

 

Any comments?

[irvinlim]

I'd like to add another scenario for the BTSync team to take a look at:

 

I run two machines, both dual-booting Ubuntu and Windows 7, and installed BTSync 2.0 without a hitch on all four OSes, where the directories are referenced at the exact same locations (eg. E:\Data in Win7 and /media/Data in Linux).

 

However, files can get overwritten if the following series of events are in order:

 

Initially, all files have been synced with all 4 OSes.

 

1) Files are modified on Machine A and is synced with Machine B on Ubuntu, 

2) Machine B switches off.

3) Machine A continues modifying files.

4) Machine B switches on and loads Windows, and overwrites newer files in A with older ones from B.

 

Understandably because in Step 1, files have been synced only in Ubuntu, but not indexed in Windows. BTSync Windows thinks the files that were synced over in Ubuntu have been fresh and unindexed when it first boots in Step 4, and thus overwrites the so-called newer files in A.

 

Because of this, I will now have to ensure that I have a primary OS I boot to first, so as to not cause these kind of problems again.

 

I would like to ask the BTSync team if this is a recommended setup for dual-booters like me - because I constantly switch between environments depending on the work I am currently doing. I was also wondering if it would be a better option for BTSync to merely compare the last modified timestamp of files when determining file conflicts - or better to pose these as options for us to choose from.

 

I really love the product and actually paid for a license, but because of this problem I recently reproduced (thank god for .sync/Archive!), I was wondering if anyone else can provide a better solution to this problem, or a better recommendation for my workflow. Of course, the best would be to have a remote server to constantly poll for changes, but that's another story. Another option would be to have separate pairs of directories for each OS... But neither are what I was initially looking for.

[iswrong]

I run two machines, both dual-booting Ubuntu and Windows 7, and installed BTSync 2.0 without a hitch on all four OSes, where the directories are referenced at the exact same locations (eg. E:\Data in Win7 and /media/Data in Linux).

 

Are you using exactly the same directories for OSes? Which filesystem?

[irvinlim]

Are you using exactly the same directories for OSes? Which filesystem?

 

Yep, exactly the same. Both systems have the exact same folder structure as I mentioned earlier. They are on NTFS. I believe the indexes are separate for each OS, so when a file is synced over from another computer when booted in Ubuntu, but since the file is now modified (updated) and when you boot into the other OS, BTSync Windows will reindex the file as a newer copy (not sure?) I'm not sure how BTSync handles file conflicts.