Robert Mah

We have a share that for some reason never finishes syncing on a few machines (including mine). Looking at the logs, I have many entries similar to the following: [2017-08-02 10:18:48.996] TF[2F25] [0x0000025502dd5700][\\?\C:\Users\Rob\Documents\ShareName\path\to\file\unsyncedfile.csv]: got metadata size 70 when I already thought it was 80 [2017-08-02 10:18:49.012] SyncPeer::RemoveFromDownloading SP:[1F31] index = 5424 [2017-08-02 10:18:49.215] TF[2F25] [0x0000025502dd2680][\\?\C:\Users\Rob\Documents\ShareName\path\to\file\unsyncedfile.csv]: got metadata size 392 when I already thought it was 467 [2017-08-02 10:18:49.262] SyncPeer::RemoveFromDownloading SP:[1F31] index = 5427 [2017-08-02 10:18:49.449] TF[2F25] [0x0000025502dd5700][\\?\C:\Users\Rob\Documents\ShareName\path\to\file\unsyncedfile.csv]: got metadata size 70 when I already thought it was 80 [2017-08-02 10:18:49.480] SyncPeer::RemoveFromDownloading SP:[1F31] index = 5424 [2017-08-02 10:18:49.480] Blocked downloading file ShareName\path\to\file\unsyncedfile.csv due Connection closed I have been able to identify which files are causing this. What's really weird is that If I remove them, the peers go to synced. But then, if I copy the files back, they go back to this unsynced state. (the files are listed as pending uploads to one of the peers and I get the above messages in my log). I have tried removing the share on my computer and the re-adding it. Same results. I'm using Resilio Sync 2.5.6 (1043) on WIndows 10. Rob

Lloyd, You're not alone. We were using reslio on a largish share that wasn't as large as yours (some 100k or so files) and it got very confused, deleting more recent files and replacing them with an older rev when a peer that had not been connected in a while came back online. Resilio sync seems *very* sensitive to the local times on the peers. It does not seem to verify that the local time is correct (I suggested this once a while back but was rebuffed). That's just a guess on my part though. We never really got to the bottom of the issue. Rob

Sync used to only crash once in a while, which was annoying but I could live with it. It is now repeatedly crashing on me before anything can finish syncing. Sometimes it says it is sending the dump. Once it said "Resilio Sync has crashed. Unable to generate crash dump. Reason: Failed to get address for MiniDumpWriteDump". Usually it doesn't seem to send a dump. I have six shares, most are fairly large at 19GB, 19GB, 18GB and 9GB in size. I'musing version 2.4.4 (732) on Windows 10 on an i5 machine with 64GB of RAM. I've attached the log file from just after a crash but before I restarted Resilio Sync. There are a bunch of .dmp files in my AppData\Roaming\Resilio Sync dir but they are empty (0 bytes in size).

I have similar symptoms: 1) Sync reports 3 locked files but when I click for info it only displays 2 files. 2) One of the files is what I think is a temp file created by Excel that no longer exists (also checked with "dir /a"). 3) It also shows a file I recently opened in Excel but is no longer open. Restarting Resilio Sync clears things up. Hope this helps in tracking down this annoying bug. Rob

There are many situations where one does not have the ability to even ask other people to set the correct time on their box. For example, I have clients who are executives who will change their clock time instead of the timezone as they travel. This screws up syncing and causes problems. I do not know which individual is doing this and it would be impolitic of me to send a message to a large group asking everyone to stop this behavior. I'd like to request that btsync stop relying solely on the system clock for timestamp accuracy. These days, it should be able to query a remote time server for the real time, compare it against the system clock, and then apply the difference to filesystem changes on that machine (and remote changes vs files on that machine). Thanks for your consideration.

I'd appreciate it if the team focused on fixing the outstanding bugs and focusing on stability before adding any new features. I believe that if btsync could improve its stability, I could convince MANY more clients to use it (and purchase licenses).

We are also seeing this problem. I have multiple folders that i've deleted multiple times, but they keep coming back! We have about a dozen machines syncing, a mix of PC's, Macs and one Linux box. They have versions are on the latest 2.3.3 About half are usually online, but some are offline for long periods of time. The share is rather large, about 27 GB. I can supply debug logs if it will help. I've been noticing this problem off and on for over a year. IMO, this is a critical issue and one that needs MUCH more attention.