Search the Community

Showing results for tags 'corruption'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 4 results

  1. I've been using Sync to keep external hard drives on two computers in sync. One of these hard drives had a hardware failure and is no longer mountable. The other half of the pair lost almost all of the files and folders. Is this normal during a hardware failure? I somehow thought that the other half of the sync pairing would survive.
  2. Hi I've got a setup with a Linux (x64) server which I keep online 24x7 with Internet access acting as "cloud" server, two Macs, one Android phone and an iPad. I recently added a Synology DS414j (arm) to the mix, planning to replace the Linux server. Using sync 2.0.120 on all platforms (except Android/iOS, but also latest versions). The Linux server is a Xen virtual machine. Initially when I was testing with a couple of folders it had only 256Mb of memory assigned and everything worked. As I started adding more files (specially while syncing a 100Gb folder) it started issuing the "Cannot identify the destination folder" error every now and then. I increased the VM memory to 1Gb a couple of weeks ago and haven't had any issues since. Now the Synology is getting the same error all the time while syncing, and it also has low memory, just 512Mb. After a couple of days I managed to get everything in sync without errors by removing all folders and adding them one by one, so it was only syncing one shared folder at a time. But after a couple of days, one of the folders is showing the "Cannot identify the destination folder" again. Could this error be caused by low memory? Because I haven't got this message in any of the Macs as far as I remember. Either that or a bug only affecting Linux, no matter the architecture (x86 and arm). Also (related maybe?) I noticed my .sync/ID files are getting corrupted. By the description of this file in the documentation I gather it's just a crypto-generated ID unique to each folder, which should remain unchanged through the life of the folder and in sync across systems sharing that same folder, right? Well, sometimes I get things like this: ls -l .sync/ID-rw-r--r-- 1 vicente www-data 2723151965 jun 2 21:29 .sync/ID Check the size of that thing! If I check the contents there's the usual binary ID stuff and then several of these: [20150602 21:29:36.231] assert failed /mnt/jenkins/workspace/Build-Sync-x64/fileutil.cpp:109[20150602 21:29:36.231] assert failed /mnt/jenkins/workspace/Build-Sync-x64/wincompat.h:409 I'm also getting those errors on the logs, on all systems (Macs/Linux/Synology), but these were on the .sync/ID file!!! Now the interesting bit: even if the .sync/ID file has that garbage at the end, as long as the initial binary key is OK, the folder syncs. I checked the folder with the "Cannot identify the destination folder" error on the Synology and the binary part is gone, there's just the assert log message on .sync/ID. Could this be the source of the issue? Somehow some logs go to .sync/ID instead of the log (some thread-unsafe library in use maybe?) and if ID is completely overwritten instead of appended, sync breaks? Regards
  3. I am having an odd problem with Sync version 2.0.85 (Win 7 Pro 64 PC to a Win 8.1 64 PC). I sent a client some files that were compressed in a multipart 7z archive, and they seem to have received a corrupted part. When they went to extract the files, two of the them would not exact. I have seen this happen before with bad FTP connections so I asked the to give me check the CRC for the files and the 7z part. 7Zip listed the files' CRCs correctly, but the part itself had the wrong CRC. I tested the file on my end and had no problem. I asked the client to delete that part so the new one would resync, by Sync still considered both sides in sync. I tried renaming it, but nothing more happened. I finally created a new archive with those files and that worked. A few days later same thing happened with different files. Having used torrents for years, I would have expected Sync to notice the mismatch and corrected the mistake. The debug logs don't show any out of the ordinary and I can't figure out how to reproduce the problem. This is clearly a bug that needs squashing, or a feature that needs to be added for all users, including the free ones. Any suggestions would be appreciated. Thanks.
  4. Since updating to .110 I have seen two issues. The most severe one involves PowerPoint files. While I'm editing a PPT file on Windows I am sometimes unable to save updates to the file. The save operation will fail and instead I have to do a save as to a different file name. I've also seen related problems. I can't say for sure this is due to .110 but to try to isolate things I started pausing sync'ing when editing PPT files. Since starting this I have not run into this error. Not a smoking gun of course but worth mentioning. I never ran into this with previous versions. Another problem which seems to be worse (or maybe I've just been unlucky) is getting the message about there being no peers and hence my Windows machines not sync'ing. The only 'fix' I have found is to either log out and log back in or restart Windows. It's pretty annoying because in the past I can't recall encountering these two issues and BT Sync was like magic.