letic

Hi guys, Sorry to revive an old thread. Just to let you know that I tested with the latest release (1.1.48) and the issue is still present with the simple use case scenario describe above. I thought that 1.1.33 fixed the issue as the Changelog stated : "- Fixed overwrite new files with old ones." but still not. kos13 do you know if a fix for this issue is still planned ? Thanks in advance LeTic

Well the use case is simple and should be fairly common for people already using another sync solution. We have folders synced between host by unison. Some are constantly updated (home folders). So if we are to switch from our current solution, the most logical for people would be to first share their host (the PC they use daily) and the replicated host second (which would have an older version of their home). In that case btsync will overwrite the most current copies by the old one on the server. Btsync seems fine for new users, but this bug IMHO makes it impossible for people who are looking to replace an existing solution. No problem just wanted to know if you considered it as a bug. Cheers LeTic

Hey Kos, Thanks for the hindsight into btsync behaviour. I think that the whole subject could fill many threads, maybe a summary table with most common use cases could prevent further incomprehension, but I am sure that you already have your hands full right now. Regarding the simple use case I used to open this thread, could you answer me simply if you believe this needs fixing and if it will be fixed in a future version ? This is quite a common scenario in our environment and I probably won't continue testing btsync if I know this will stay this way. Thanks in advance Cheers LeTic

Hey kos13, Thanks for the reply. I understand your usecase but as said by rdebath and hawibtsync I also believe this should be a conflict when a file is replaced by one that has a older timestamp, this is probably a different/older file. The original use case remains. Host partially synced by another method (unison/rsync/dropbox whatever) will fail as in people's logic they will always share the host that had the most recent copies of his files not the other way around. Hope this help LeTic

I had a look at the logs and there is something clearly wrong during the timestamp detection. This is an excerpt from the hostB logs (the host that is sharing the files and have the more recent file timestamps) : [20130427 12:49:51] Got id message from peer LeTic idefix - btsync server (88D47FA93F2A0B698886BFD853D3F23A63575060) 1.0.134 [20130427 12:49:51] Merge: processing root message, remote hash F0B403102AD4C49DC22B7DAE7BAB0E1D7B8A89F6, timediff: 0 [20130427 12:49:51] Merge: requesting elements for root [20130427 12:49:51] Merge: processing elements message for [20130427 12:49:51] Merge: will request file for /1, ltime:1369651713 lhash:0AB28019C04B5615D780753D5D708CAAB040457A rtime:1369651791 rhash:72068E7D91A8ABB40EBADD1A18D539A1B063 1EC5 [20130427 12:49:51] Merge: will request file for /2, ltime:1369651713 lhash:644BDED24E5A1B15BCC688F99B2C7A93561CC684 rtime:1369651791 rhash:D32683D5D35CA5C092D089992453C1ADF6E4 5D4C [20130427 12:49:51] Merge: sending get_files message [20130427 12:49:51] Merge: processing files message with 2 files, timediff: 0 [20130427 12:49:51] SyncFilesController: Got 2 files from remote (192.168.1.95:17464) [20130427 12:49:51] SyncFilesController: Got file from remote (192.168.1.95:17464): 1 state: 1 type: FT_FILE total:64 have:64 t:1369651791 mt:1369649385 A659E6EAD895FA11FFEA8D4 3B92C11CC82AB4278 [20130427 12:49:51] SyncFilesController: remote file 1 is newer and different from local. Removing local torrent. [20130427 12:49:51] SyncFilesController: Got file from remote (192.168.1.95:17464): 2 state: 1 type: FT_FILE total:640 have:640 t:1369651791 mt:1369649420 64D32D02F3EF8D080DCAA F425FA33D8AC164926E [20130427 12:49:51] SyncFilesController: remote file 2 is newer and different from local. Removing local torrent. [20130427 12:49:51] State sync finished for folder /home/letic/btsync_test As I showed in my original post the local timestamp (ltime) should have been somethng around : date -d "May 27 12:45" +"%s" 1369651500 while the remote (rtime) actually is : stat -c %Y btsync_test/1 1369649385 Interestingly the local detected timestamp : date -d @1369651713 Mon May 27 12:48:33 CEST 2013 corresponds to the time the folder was shared on HostB, it even appears as the last parameter to the webgui "&t=" [20130427 12:48:33] HTTP: IP 127.0.0.1: GET /gui/?token=seGvHc8DHbvSwn4cj8CO8H3a-vsiqoNYjp7VN50nemCPPGoJu_ZwGvY5o1EAAAAA&action=addsyncfolder&name=%2Fhome%2Fletic%2Fbtsync_test&secret=FT74ESZJZDC4AW7C4OKA2HMLB3ENWD3R&t=1369651713720 [20130427 12:48:33] SyncFilesController: started periodic scan [20130427 12:48:33] SyncFilesController[file updated]: processing file /home/letic/btsync_test/1 1369651552 1 The same is also true for the remote which timestamp (1369651791) is the one from when the folder was added on HostA. So from these logs we can understand several things : Btsync should only be used with an emtpy remote directory, if not, you HAVE to make sure (using rsync or unison) that both copies are identical If you still want to sync folder that are partially synced then you should create the share on the host that has the oldest version of files and then add the one with the newer files, this way the behaviour should be correct It is not yet clear what happened on reconnects. What timestamps are used then ? I'd venture a guess that it's using the time the machine's reconnected thus resulting in old files overwriting newer files. This seems quite a bogus way of working so I guess this is just a nasty bug that crept up, or a specific usage case the developers haven't tested. Waiting for confirmation from the official devs. Cheers LeTic PS : I know the secret is in the excerpt (it's also in the atatched logs but this is only a test folder that has already been deleted)

Hi guys, I was testing btsync to see if it could replace unison in my setup, and hit a very nasty bug that seems to be frequent for a couple of users (ie http://forum.bittorr...by-older-files/ ). As it seems to be reproducible in all my tests I decided to set up a very simple environment to reproduce it. I don't think the configuration matters much as people in the forum seems to have the issue with Windows and Mac as well but here it is anyway : btsync 1.0.134 debian sid on both nodes one is amd64 the other i386. Tested also with a freebsd 9 server (Nas4Free x64) use the package provided by http://debian.yeasoft.net/btsync conf on both node (running as the user letic) : { "device_name": "LeTic - btsync Server", "listening_port" : 0, "storage_path" : "/home/letic/.btsync2", "check_for_updates" : false, "use_upnp" : false, "download_limit" : 0, "upload_limit" : 0, "webui" : { "listen" : "0.0.0.0:8888" } } Here are the steps to reproduce (host A is 1386, host B is amd64) : On Host A : mkdir btsync_test cd btsync_test Create a 1M file : dd if=/dev/urandom of=1 bs=1024 count=1024 Create a 10M file : dd if=/dev/urandom of=2 bs=1024 count=10240 Check the resulting timestamp. ie for me : ls -la total 11268 drwxr-xr-x 1 letic letic 4 May 27 12:26 . drwxrwxr-x 1 letic letic 574 May 27 12:00 .. -rw-r--r-- 1 letic letic 1048576 May 27 12:09 1 -rw-r--r-- 1 letic letic 10485760 May 27 12:10 2 On Host B : mkdir btsync_test cd btsync_test Create simple 1 and 2 file : echo "blabla" > 1 echo "test" > 2 Check the resulting timestamp. ie for me : ls -la total 24 drwxrwxr-x 2 letic letic 4096 May 27 12:45 . drwxr-xr-x 89 letic letic 12288 May 27 12:45 .. -rw-rw-r-- 1 letic letic 7 May 27 12:45 1 -rw-rw-r-- 1 letic letic 5 May 27 12:45 2 On Host A and B enable debug with debug.txt and start the btsync daemon On Host B add the btsync_test folder through the webgui. I just click on generate and choose the folder (so it use the default writable conf) In the GUI I get : /home/letic/btsync_test - 12 B in 2 files On Host A add the key from host B and choose the corresponding folder File from Host A are uploaded on Host B and replace the files that had a newer timestamp. Here is the result on Host A : ls -la total 11292 drwxrwxr-x 3 letic letic 4096 May 27 12:50 . drwxr-xr-x 89 letic letic 12288 May 27 12:47 .. -rw-rw-r-- 1 letic letic 1048576 May 27 12:09 1 -rw-rw-r-- 1 letic letic 10485760 May 27 12:10 2 -rw-r--r-- 1 letic letic 32 May 27 12:48 .SyncID -rw-r--r-- 1 letic letic 783 May 27 12:48 .SyncIgnore drwxr-xr-x 2 letic letic 4096 May 27 12:48 .SyncTrash Stopped both daemons Of course I attached both debug log, Hoping it will help you. Let me know if you need any more info. Cheers LeTic PS : Also sent to support email synclogs.tar.gz