RomanZ

@Jay Siquelus Is your Admin account active? Sync won't be able to run with disabled admin account. If yes - let's try to SSH to NAS and run Sync manually - it should display some error on why binary does not start. After logging in under admin, run the following command line: /usr/local/bittorrentsync/bin/btsync --config /usr/local/bittorrentsync/var/sync.conf And let me know the output.

@kotor610 Sync is receiving messages from OS about network adapter state change. So the delay should be minimal. BTW, did you notice what exactly happens when Sync loses its connectivity? Anything specific?

@mzosama I strongly suggest checking exact paths of folders you sync (you can just hover a mouse over folder and Sync will display the path). It is very common mistake that one starts syncing files not to a designated pre-filled folder, but into subfolder. For example, you want to sync C:\Docs\Engineering from PC A to PC B, and you get it synced to C:\Docs\Engineering\Engineering on PC B (which is obviously empty and will require full data re-transfer). Also, please take a look at this article, it may help to properly configure folders.

@Olotila I wonder "admin" user is active on your Synology? It is totally necessary for Sync to function.

@nuts You'll need to connect to your NAS over SSH protocol, locate the binary and replace it. Here is kind of instruction for you 1. Connect to your NAS over SSH. If you are on windows - you'll need a putty tool. See instruction here. If you are on Linux of OS X - just open a terminal window and type "ssh root@<your_nas_ip_or_name>", it'll prompt for password and you are there. 2. Locate your binary. For Asustor it always stays here: /volume1/.@plugins/AppCentral/bittorrent-sync/app so just change your current dir with cd command. 3. Replacing binary Rename it to something else for beginning: mv btsync_arm btsync_arm_old then get the new binary there: wget https://download-cdn.getsync.com/2.3.7/linux-armhf/BitTorrent-Sync_armhf.tar.gz unpack the archive: tar zxvf BitTorrent-Sync_armhf.tar.gz and finally rename the binary that was in archive to "btsync_arm": mv btsync btsync_arm Try running your Sync and see if it works.

@Falconm11 Please try to do the following: 1. Open command line prompt, navigate to the "C:\ProgramData\BitTorrent Sync" and find 2 DLLs there: ShellExtensionOverlay64_xxxx.dll and ShellExtensionOverlay86_xxxx.dll, where xxxx could be random alphanumeric value 2. Run 2 commands: regsvr32 -u <DLL_NAME> 3. Restart explorer or computer and let me know if it helps.

@JSF Docker image with Sync 2.3.7 is now publicly available - JFYI. @jpsimmonds I wouldn't call it security reduction. Syno was working just fine with admin allowed till DSM5.2. They are improving their security by disabling admin. Though, we are aware of it and will definitely check the possibility of moving Sync from admin account. @David Loke We are working to get back to official store. So, if under "this issue" you mean the message that Sync is not compatible - no, it is not yet resolved. Although, if you need to get your Sync working on DSM6 you can simply grab Sync package here and manually install it.

@Gavthirdphase It's specs says it is built on Armada 385 CPU, so technically should be working fine with Sync. Although, it was never tested in our labs, nor our users reported anything about DS116. Sorry - not too much info.

@Konstantin_J Unfotrunately, Sync is not compatible to uTorrent or Maelstorm project. So you can't convert a BTSync link to torrent or vice versa.

Still planned to get fixed. Likely, will be new property field in /client call.

Oleg, You understand correctly. When syncing data from Android to other platforms, Sync let know the real mtime of a file, not the one assigned by Android. The only exception is when file gets modified on Android - in this case, the mtime assigned by OS becomes true. Shouldn't be the problem since 2.2 release for sure (maybe even earlier).

@Khuli Thanks for bringing it to our attention. It's already fixed, fix will be included in one of future builds.

@Khuli Could you please send us debug logs so we can check what went so terribly wrong with auto update?

@NNois Could you please elaborate on what you mean that folders get disconnected? Do you see them outlined with dashed line (like ) or your list of folders is simply empty? Screenshot would be great. 1. There is an article describing adding your pre-populated folders. Note deleting extra folder name - important step. 2. It depends on the problem you encountered. If all your folders are simply gone, we've encountered it in the past and get it fixed starting from 2.3.4. It also could happen if something damages Sync internal files, especially sync.dat. BTW, note, that sync.dat is backed up to sync.dat.old every time it is saved, so you have a small chance to bring back all folders if you rename back sync.dat.old to sync.dat. 3. See above in p2

@spivoler We've found one more issue that could be related to increased CPU usage. I suggest to wait a bit for a new build (should be soon) with a possible fix.

@airzoink I guess, you did?

@Spartakus As Sync Team is not very large, we have pretty finite resources. So every time we choose to support some OS / platform it means we'll lack manforce in some other area. Opposite is also true: when we drop support of some platform, we can spend our time to support something else or design a new feature or just improve product stability at the end of day.

Exactly. Your explanation is much more elegant Devs did a whole research on the topic. Some distros were okay to set mtime, some not, some required additional actions like setting creation time. At the end of day we came to conclusion that it is more effective to store real mtime in our DB rather than craft Sync for every distro. Sorry, we don't have this information anymore. It was really long time ago. Once we've found a solution, we no longer keep track of such differences.

No, new PeerID is not generated during update. Only when installing and when you migrate / clone Sync.

@C hris You'll need to SSH to your NAS to get logs. See here exact location of logs, you'll need to collect sync.log and all sync<timestamp>.log.zip files. Submit logs to our helpdesk, note this forum topic in message subject.

@ogrfnkl For the file creation time - it is not something we adjust. For the mtime - this is Android distro limitation. Sync adjusts mtime after delivering files (but not folders) on all platforms, although on many Android distros the OS itself reports successful mtime adjustment, while actually keep old mtime. To track things correctly, Sync has to store real mtime of a file in its DB.

@aaljr Peers are identified not by IP, but by unique PeerID instead. It is generated once you install Sync and when you change your hardware (it relies on your Volume ID). So it is likely appeared if you reinstalled Sync or used some cloning software which could mess up with volume id. Unfortunately, there is no way to get rid of them now, though in future they'll be removed to special section to avoid floating in front of you all the time.

It's okay, it just means your logs never rotated yet.

@whoever-reads-this-topic The issue seems to only appear when one is using parallel-nested folders (see diagram below) and is totally okay if you use nested folders on one computers that are linked to separate folders on other computer(s). While we are working to get it solved, it is advised not to use parallel-nested folders.

@airzoink Well, then I suggest collecting logs from all your peers and opening support ticket. We'll do our best to find our what happens.