bisente Posted June 2, 2015 Report Share Posted June 2, 2015 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 Quote Link to comment Share on other sites More sharing options...
RomanZ Posted June 5, 2015 Report Share Posted June 5, 2015 @bisenteWe are aware of this issue and working to fix it. As a workaround, you may try the following:1. Go to your storage folder (the place where Sync stores all the DB files and service data).2. Create a debug.txt file.3. Put the "00000000" value there (eight zeros, no quotes).4. Save and restart Sync. It should no longer corrupt your ID files. Quote Link to comment Share on other sites More sharing options...
chris_bramley Posted June 19, 2015 Report Share Posted June 19, 2015 @bisenteWe are aware of this issue and working to fix it. As a workaround, you may try the following:1. Go to your storage folder (the place where Sync stores all the DB files and service data).2. Create a debug.txt file.3. Put the "00000000" value there (eight zeros, no quotes).4. Save and restart Sync. It should no longer corrupt your ID files. i've been trying to run this between two Synologies (213j -> 215j) for weeks now on the latest version 2.0. NOTHING but constant database errors and ID file corruptions. I have tried this above fix - didn't work. I'm looking at other sync applications at the moment, as 4 weeks and still only 3/4 through syncing less than ten folders across 1.7TB of data on GB lan is crazy, and I refuse to offsite the second NAS if it is not reliable. The database errors aren't ideal but could be lived with, I guess. The corruption is not livable with and breaks this entire product. no way I would consider going pro under these conditions. It is also maxing the CPU on both boxes up to 100% a lot, and consuming a lot of memory - something no other app has done on either NAS. If there isn't a fix very shortly, I will move to anything else no matter how painful the move, as ongoing pain is worse! Quote Link to comment Share on other sites More sharing options...
RomanZ Posted June 19, 2015 Report Share Posted June 19, 2015 @chris_bramleyThis one was properly addressed in 2.0.125 which was released recently. What is precise version of "the latest"? Quote Link to comment Share on other sites More sharing options...
bisente Posted June 19, 2015 Author Report Share Posted June 19, 2015 @chris_bramley, as @RomanZ said this bug seems to be fixed on 2.0.125. I can confirm I haven't had any issues since I upgraded yesterday, in fact since I upgraded to a test build the developers sent me 10 days ago. PS: enabling debug with the old builds did NOT fix the issue. The new 2.0.125 does. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.