bisente

New Members
  • Content Count

    9
  • Joined

  • Last visited

About bisente

  • Rank
    New User
  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 prob
  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 depend
  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 scratc
  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
  8. Hi I keept looking into the issue I described at http://forum.bittorrent.com/topic/39034-cannot-identify-the-destination-folder-related-to-low-memory-also-possible-syncid-corruption/ 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 2
  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 id