• Content Count

  • Joined

  • Last visited

About letic

  • Rank
    New User
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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:
  6. 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 h