RomanZ

@kenneito All users should be able to edit their own posts. Sorry, wanted to leave a link to FileDelayConfig article so you can find it easily. For the FileDelayConfig - the file is pretty flexible. You can remove all the filters there, leaving simple "*" : 10 to force delay for all files. Just keep the JSON syntax so Sync can parse it.

@NaCkHaYeD It is okay. Note, that your NAS peer keeps connection to other peers that still DO have 10 minutes rescan interval. So if they notice some changes - they'll let your NAS know and do actual Sync (and, of course, wake up HDD). So your HDD will sleep if nothing is actually changing also on other peers.

@derBoris Yep, your assumption is correct. Sync is only working on file-level and is definitely not able to merge any data inside files. So, in your worst case you'll lose changes in DB made on Mac1. For the edge cases. I'm aware of couple of cases for OS X (and actually other POSIX OS) when Sync may miss notifications: there is not enough inotifies in OS (we use inotify to subscribe to changes), though this usually happens more on Linux rather than on OS X some really massive changes (thousands of files) happen in a very short period of time

@abramq It is due to OSMC peculiarity - it has no linker used by Sync in /lib. Try fixing it with command: After that you can launch Sync with systemctl. Worked fine in my lab.

@abramq I did. Installed on number of Linux distros for both intel and ARM CPUs. There is something special about OSMC - I managed to reproduce issue easily. Will check what is the possible reason and let you know.

@kenneito Not 100% sure what exactly happens in your case, but in general when you encounter some compatibility issue with other apps there are 2 ways in Sync to workaround it: IgnoreList to ignore files that your want Sync not to touch FileDelayConfig to force Sync to not to touch file for some time after it changes (based on extension of a file).

@derBoris Sync detects changes via rescan (slow and reliable) and OS notifications (extremely fast, but unreliable). There are a number of edge cases when OS notifications may fail, therefore Sync uses both methods simultaneously. If you does not need Sync to happen more often than once a day - you can set rescan to once a day. As for your NAS - if you don't ever change data on NAS (changing over SMB/CIFS also counts!) but only use it as device which always run and ready to seed data - you can disable rescan there at all. And in general, take a look at this article regarding letting NAS sleep :).

@zvitwersky Selective Sync works slightly differently. When you enable Selective Sync on some peer, it won't sync files automatically anymore. It will only keep synced those, which you explicitly select. Although, if you have 2Gb of data and, for example, 1Gb of this data is selected by you to be synced and other peers change 500Mb of that data, there is no way for you to prioritize your 15Mb file. Sync will decide on its own how to deliver these 500Mb of changes. In short Selective Sync feature won't let you prioritize downloads. Yes. Only owners of paid version can use Selective Sync.

@pks They won't work anymore. The folder no longer exists in Sync. Only one exception I can think of is that the peer where you removed folder could not contact all other peers in your "My devices" mesh and share the fact that folder is disconnected.

@wowhsieh No. Sync saves version in Archive, if: File has changed It was changed on another peer so Sync delivers changes It means that if you change the file on peer A, you won't find old version in archive on peer A (but it'll be archived on peer B). Also, if no changes in file body - no one is going to archive it.

@HardyG It looks like both are using ARM CPU so should be working fine. While, it never has been tested in our lab explicitly, there is at least 1 report from our customer that Sync is working on ReadyNAS 204 model.

@donmez Ok, we'll fix it. @abramq Unfortunately, some issues are rather sophisticated and manage to bypass our QA testing. We constantly improve our set of tests to keep such issues covered, although keeping in mind vast variety of devices and OS Sync supports, it is hardly possible to cover everything.

@Shad0wWulf We can take a look into debug logs to identify why it does not sync, though we'll need logs from at least 2 peers of yours - ones that does not send files and another which does not receive'em.

@NaCkHaYeD Did you try to apply whole bunch of settings to let HDD sleep?

@Colin49 Unfortunately, yes. You have to re-add them manually via keys or links. I apologize for inconvenience. It should not happen anymore if you update from 2.3.4 or 2.3.5

@KawateTadako Thanks for the fresh logs. There is something very special about your filesystem. It looks like the ID of every folder changes rather often, and new Sync (starting from 2.3) is actively using it. We'll do our best to find our why it happens and address it.

@had-to-reregister @all Actually, there is an issue between DSM 6 and DSM 5. For certain platforms DSM6 require ARMHF build, while DSM5 requires ARMEL build for exactly same platform. We want to avoid making 2 flavors of package for every platform. Therefore all existing packages are being built with target of DSM5 (as DSM6 is still in beta). If your package does not work well and Sync does not start on DSM6.0 - you'll have to manually replace Sync binary to ARMHF. Binary always stays in "/usr/local/bittorrentsync/bin/btsync" for all Syno devices.

@The Dave Very nice proposal. Some users already encountered same issue, though none formulated such a feature request IIRC. I suggest mentioning in our Feature Requests branch so it won't be lost and people can add their votes.

Dear community, Sync 2.3.5 is now available. You can get it via direct links below, via official download page or via "Check now" button. Build is not yet available via auto-update. Direct Download Links: Installer for Windows: x86 installer x64 installer Package for OS X: OS X package Gzip archive for Linux: arm armhf i386 x64 glibc23_i386 glibc23_x64 Gzip archive for FreeBSD: i386 x64 A list of what's new, improved, changed, and fixed in this version is available in the change log. Latest Android build is now also available via direct link: 2.3.5 APK Latest Raspberry Pi package is available via direct link: 2.3.5 DEB Known issues and peculiarities: - Linux users please note: starting from 2.3.0, Sync now creates and uses storage folder (.sync folder) in current directory, not next to binary - Upgrading from 2.3.0-2.3.3 may remove your identity and folders. It is strongly advised that you backup your storage folder prior to upgrade to 2.3.5.

@The Dave When peer is using LAN discovery or tracker server, it will tell other peers about peers it knows. Also, Sync tends to cache IPs of peers it talked to, so even when you disable all discoveries, it still remembers the IP in cache and will attempt to connect. If you want to isolate someone, you need to disable his tracker and LAN discovery and use predefined hosts only. Also, you can flush cache by temporary setting the "peer_expiration_days" power option to zero and then back to default value.

@leopinheiro Known by us. It means that we are aware of the issue and fixed it in future builds. We avoid sending extra updates to our customers as users start treating such mails as "spam". I would ask you to keep our conversation constructive and keep it around issues and with respect to all conversation participants. We do not have chat or phone support. Feel free to contact us via our Help Desk support form. We'll do our best to restore your identity, although my experience indicates that in majority of cases like yours it is not recoverable. @carloxp for all Syno products that would be /usr/local/bittorrentsync/var

@kamborio Try 2.3.4. There was indeed memleak so it may help you. For the #2 - installer prompts for the name of user to run under. Type in "LOCAL SERVICE", leave pass empty.

It's already out. 2.3.4 and upgrades from 2.3.4 should not lose any folders / identities anymore.

@HonzaC I'll be more than happy to debug and get it fixed. Give me a mail via our Contact support form, mention this topic in message subj. For initial stage of debugging - please send me couple of screenshots on how the issue looks like on your Android devices. Thanks!

@carloxp It should (mostly) affect RAM consumption and should result in around 750Mb of memory allocated for Sync (can be a bit more or less depending on how short or long absolute files paths are). For the CPU - it could happen that we've fixed it with today's release.