New Members
  • Posts

  • Joined

  • Last visited

bisente's Achievements

New User

New User (1/3)

  1. Hi I just wanted to report that I upgraded my DS415+ (avoton) yesterday to DSM 6.0-7321 and Sync works. I had Sync 2.3.5 installed before the upgrade. During the upgrade I got the warning about Sync not being supported, the upgrade was aborted and the system restarted still with DSM5. Then I went to package manager and stopped (not removed) Sync, and attempted the upgrade again. Upgrade went ok this time, restarted with DSM6, went to package manager, upgraded all pending packages, and then started Sync (was still there, stopped, hasn't disappeared). Sync has been working without problems since the upgrade. For the record, my sync volume is in /volume2 and my admin account did have a password before the DSM upgrade. Haven't tried to upgrade to Sync 2.3.6 yet. Regards
  2. Hi Ok @RomanZ, so this is a known issue with accents and other "combined" characters. Good to know. For the record, I've been quite busy and couldn't take the time to do tests and get logs, but what I did is deleting the shared folders with this .Conflict issue (completely, from all systems), recreate them after removing all the .Conflict folders/files on one Mac and then share/resync in all the other systems. No issues since then, but after reading @RomanZ I guess it could be just a matter of time until this happens again. Maybe it has to do with where a file is created, then depending on how the "origin" OS treats the compressed/decompressed UTF filename it's shared that way to all the others leading to .Conflicts if the "receiving" OS doesn't use the same compressed/decompressed representation? Could this UTF compression/decompression be "normalized" in transit or upon receiving the file, depending on the OS? Regards
  3. Hi I just noticed I'm also having this problem. Not sure when it started happening but I'd say not too long ago, definitely sometime after upgrading to 2.3 around a week ago. Worth mentioning, it's only happening for the moment in one particular shared folder, and only folders with accents on the filename (e.g. Títulos, Energético, Begoña, etc.) are getting these .Conflict, .Conflict1... .ConflictN siblings. No .Conflict in any folder without such characters. I'll try to get some logs during the following copule of days, and try to drop the shared folder and re-sync from scratch. For the record my setup includes one Synology DS415+ (Avoton), two Macs running El Capitán, one Android phone and one iPad, all updated to the latest versions (2.3.1 for the Synology and the Macs, latest version on the app stores for phone and iPad). Regards
  4. @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.
  5. @RomanZ, just updated to 2.0.125. Everything OK so far, but I've noted the version number on both the Mac, Linux and Synology builds says 2.0.125 (32). That (32) wasn't there in previous builds. Thinking it might mean a 32bit build I've verified all the binaries with "file" but they're 64bit. Just wondering what that means. :-)
  6. Managed to reproduce the issue. Just submitted the logs through your Zendesk support portal, request #26609.
  7. Hi @RomanZ Thanks for your answer. Glad to know you're already aware of the ID issue and working on it. In any case I'm sorry to report that I'm still having corrupt IDs even after enabling debug move. Yesterday I disconnected/removed all shares and deleted all .sync folders from all my systems, and started creating the shares again and connecting all the systems one by one. In some cases I've got ID corruption again. Then I deleted those folders again, re added, and sometimes they finished syncing without corruption. This doesn't happen 100% of the times, sometimes the folders sync right and stay OK. Sometimes the ID gets corrupted during the initial sync, sometimes after some hours/days it seems. If I have some time this weekend I'll pay attention to the logs and try to reproduce the issue again. I mean, I don't have a recipe like "go here, do this, do that and it fails". But after disconnecting/connecting a share, 1 out of 5-6 times I end up with corrupted IDs. Specially on the Synology (ARM), it's just a matter of time until the ID gets corrupted. I'll email some logs to support if I can pinpoint exactly when (how?) the corruption occurs. As for the corruption to other (synced) files, please see the following links (couldn't find how to attach to the post): That one was a simple text file with some notes. Completely overwritten by the log messages. Zip file. In this case the log message is prepended to the actual file content. Run "head -n2" or strings on Linux to see what I mean. I've also seen cases where the logs have been appended to the end of the file, can't locate samples now. Corruption to synced files is rare, but it happens.
  8. Hi I keept looking into the issue I described at a couple of days ago, and found out the "assert failed" corruption not only affected .sync/ID, but also some of the synced files!!! This a serious issue. If btsync is randomly appending these messages to some of the synced files (sometimes completely overwriting the files), it can't be trusted. This needs attention, and needs to be fixed. E.g. I found this at the end of a keepass (binary) file: [20150602 20:40:12.521] Disconnect: Is seed[20150602 20:40:12.521] assert failed /mnt/jenkins/workspace/Build-Sync-x64/fileutil.cpp:109[20150602 20:40:12.521] assert failed /mnt/jenkins/workspace/Build-Sync-x64/wincompat.h:409 Notice the date and the "Build-Sync-x64". I did modify the keepass file at that time on one of the Macs, but it seems the file got corrupted during sync to my Linux server (the assert for a Mac build is different, Build-Sync-Mac instead of Build-Sync-x64). And then the file was synced back to all systems, including the Mac where I did the edit. This happened just two days ago, running sync 2.0.120 PRO on all systems. Any sync representative can shed some light on this issue? Is it being investigated? .sync/ID corruption is annoying, but synced file corruption is a nasty bug. Regards
  9. 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