GreatMarko

That's right - if you're creating a standard "read-write" share (as opposed to a "read only" share), it doesn't matter which device you start from

Yes! You'll need to install Sync on both devices, and add the location where your music is stored on one of your devices. Once the folder has been added, copy the folder's "key" from within Sync's UI, and enter it into Sync on your other device. On this second device, set the incoming folder's destination to the location where your music library resides on that device. This will link the two folders together. Sync will work its magic to determine which files are missing on either device, and which device has newer files, etc and transfer accordingly. The end result being that you'll have two folders "in sync" (i.e. the contents will be the same in both)

@all The comcerto2k package is now available.

Have a look at the Bandwidth/Sync Scheduling feature request thread.

If you're running on an system where changes to files/folders are not reported to Sync by the underlying OS, and therefore Sync relies on regularly scanning folders to detect changes, you could simply increase the "folder_rescan_interval" from "600" (seconds = 10 mins), to "3600" i.e. 1 hour. However, on systems where changes are detected instantly, your only real work-around at present would be to setup a Schedule Task in your OS to run Sync for a few minutes every hour, and then exit it.

Thread closed, as this topic is already covered by this thread.

There isn't a published public "roadmap" as such, as sometimes features may take longer to implement than anticipated, and so it would disappoint users if it was stated somewhere that a particular feature would be included in a certain release, only for it to then end up being delayed until a later release. However, I think you will be happy with the forthcoming 2.3 release!

"syncshellextension86_xx.dll" is a component which enables Sync's Windows shell extensions - such as context menus when you right click on a folder in Windows (i.e. you'd normally see a "Share with BitTorrent Sync" link in the folder's context menu). If you downloaded Sync from official sources (i.e. from getsync.com), then nothing should be "piggy backing" on the Sync install or on this .dll You can view the VirusTotal analysis for the latest x64 version (Sync 2.2.7) here.... as you can see it's clean. So if you downloaded Sync from an official source, then Norton is detecting a "false positive". If Norton has quarantined or removed this dll, Sync should still function, but Windows shell extensions won't be available.

As cipherplain indicates, Sync 1.4.65 was the last version supported on Android 2.3. It won't support "Advanced" (2.x) folders, but will support "Standard" (1.4) folders - that doesn't mean that you'll need to run a "separate" instance of Sync though - I have 1.4.65 running on a Android 2.3 device, and syncing with desktop devices running the latest Sync 2.2.6 without issue!

Before reinstalling Windows: 1) Exit Sync 2) Backup (take a copy of) your %AppData%\Roaming\BitTorrent Sync folder 3) Re-install Windows 4) Install Sync 5) As soon as Sync has installed, exit Sync (without setting anything up) 6) Restore your previous %AppData%\Roaming\BitTorrent Sync folder back to the same location 7) Restart Sync, and all your previous Sync folders/settings should be there!

Please check that you don't have any browser extensions/addons (i.e. AdBlock) running which may be interfering with the correct display of the Sync UI in your browser.

Not quite; only changes from your "master" device will propagate to other devices, however once those changes have been received by one of those devices, it will also start contributing to propagating those changes to the other read-only devices in your "mesh" to help all the other read-only nodes get the master changes quicker. Assuming all devices are read/write and online, then whichever has the "newest" copy of a file will propagate to all other devices. This may temporarily be different if one or more devices is temporarily offline. For example, let's say you have three devices which are currently out-of-sync. Device A has the "latest" version of a file, device B has the second latest, and device C the third latest. If A is offline, the file on device B will appear to be the "latest" and will propagate to C. However, assuming no other changes to the file, once A comes back online, Sync will see that A has a newer version of the file than B or C have, and so the file from A will then propagate to B and C

l1nu5_, before sending logs to support, it might just be worth checking that the files/folders in question aren't being excluded from syncing with an exclusion rule.

Firstly, are you using the most recent version of Sync (which at time of writing is 2.2.5)? If not, please update to 2.2.5 to see if this solves your issue (for instance, 2.2.0 contained a fix for "Newer file replaced by old one from offline peer") If updating all your peers to 2.2.5 does not resolve your issue, please share your "easily reproducible" steps

Bumping your own topics is not appropriate in the Feature Request sub-forum - it won't get your suggestion for a feature/improvement implemented any sooner. A quick glance over the Sync forums will demonstrate that Sync is far from "abandoned" - it is in active development (in fact, a new update was released less than two weeks ago!) Again, a quick glance over this forum will show that this isn't the case. This is a very active sub-forum, however, do however "merge" similar/identical threads on the same theme into single threads i.e. 1 thread = 1 suggestion Developers do frequent these forums, and do keep tabs on the ideas/suggestions posted within the Feature Request forum, and their respective popularity. Just because a thread doesn't have response from a developer doesn't mean it's not been noticed or is being ignored! Do search this forum for the phrase "Now Implemented", and you'll see that plenty of user-contributed suggestions have gone on to be implemented within Sync.

I've done it for you!

Thread has been marked "[solved]", but will remain as your solution may be of use to anyone else who encounters this!

...but then you'd end up with a MODIFIED timestamp reflecting an earlier point in time to the CREATED timestamp! ...and might that cause issues with some apps/OS's because technically a file can't be modified before it's even been created!

It's actually a little lower than that - around 300-400 bytes per file There is no "enforced" limitation on the number of files you can sync, however, it will be affected by factors such as free disc space, available memory, etc. It's impossible to say, especially without knowing things like the size of files - as 100 million 1KB files would take a different total time to sync than 100 million 100MB files(!). Generally speaking though, it's quicker to sync when the two devices are on the same LAN, rather than across the internet, so you may achieve better sync speeds if you setup a VPN between your two servers so that they appear on the same physical network.

You don't provide all that much information to allow us to assist - however, if some files are syncing yet others are not, it's possible that the ones that aren't have been excluded from syncing by default by the exclusion rules in .sync/IgnoreList. Without more information as the the specifics of your issue, I'd suggest checking out the Sync Help Center, and articles such as this one and this one.

Please go to https://www.getsync.com/buy/upgrade to upgrade your license.

Please see this Help Center article.

You'll find the answer in this Help Center article. If you're going to do that, why not just set it to zero and disable it completely, as outlined in the aforementioned Help Center article.

Please see the "Android 4.4 KitKat and 5.0 Lollipop compatibility note" at the bottom of this article.

Please consider adding your voice to this thread in the Feature Request forum.