GreatMarko

Looks like there's a problem with the main download link - thanks for flagging it up! In the meantime, you can also obtain the latest Mac client via this direct link.

The best advice would be to educate those enforcing the blocks that not all bittorrent/P2P traffic relates to downloading illegal/copyrighted movies/games/software etc, and that Sync is an application for keeping you own files in sync between your own devices, it's not a "torrenting" client for downloading illegal content! As you can specify/change Sync's listening port, you could perhaps talk to those responsible for blocking P2P traffic, explain what Sync is and how it works, and see if they're willing to open up a dedicated port for you to use with Sync.

Such functionality already exists - when you add a new device to "My Devices", you can set it as either "Connected", "Available", or "Synced". - try connecting your devices as "Synced"

In relation to your questions: 1) It's a security restriction of KitKat, which only allows apps access to a single location on an SD card, rather than access any part of it. This restriction, however, has apparently been lifted for Android 5. 2) It's a limitation of the Sync iOS app that it needs to be running in the foreground for syncing to take place. The developers are aware of this and hope to address it for a future update.

On iOS, Sync needs to be running in the foreground for syncing to take place. "Rooting" your device is unlikely to change this. The developers are aware of this current limitation and are hoping to address it in a future update.

No, provided that the folder contents on both devices is still the same, Sync will simply re-index your folders but nothing will transfer as Sync will detect that they are already in sync.

Please can you be a little more specific as to when & what's prompting you for these credentials? Windows itself, or is it when you actually access Sync in your web browser?

Just tap the "Send Feedback" option within the Android app. Prior to sending your message the app will ask you if you wish to attach debug logs with it.

You're welcome! Glad you've sorted it!

Very strange indeed! Although, as you're seeing the same issue outside of Sync (i.e. in your browser when viewing these forums), it's not going to be an issue specific to Sync. It's potentially more of an issue with your graphics card/resolution/display drivers. First, try changing your screen resolution first to see if that makes any difference, but it's more likely to be an issue with the actual display drivers themselves. Consider re-installing/updating them, or contact the manufacturer of your graphics card for further support.

It should be a Hexadecimal DWORD:

Try using a service like http://postimage.org/ if you're unable to embed your image within your post directly

You may not be aware, but there's actually an API available for Sync.

You can specify "force=1" with the "add_folder" API call. Please see this article.

The behavior you describe sounds very much like you're either somehow running two parallel instances of Sync which are acting on the same set of data, or you have Sync and another file synchronization app operating on the same set of data at the same time. Ensuring that: 1) You only have one copy of Sync running at any one time (i.e. multiple user accounts are not logged in to your computer at the same time, each of which are running a copy of Sync, and acting on the same set of folders), and 2) No other file synchronization-type software is running at the same time of Sync will likely solve your issue. However, if you're unable to resolve your issue, then in answer to your question.. Start Menu -> Control Panel -> Programs & Features -> BitTorrent Sync -> Uninstall. During uninstall you'll be asked whether you wish to delete all settings, select this option. Finally, once uninstall is complete, remove the folder %appdata%\Roaming\BitTorrent Sync

It's 7 days by default, but can be changed via the advanced "peer_expiration_days" setting

It depends on your operating system. Where Sync receives real-time OS notifications that a file has been added/modified/removed, it will immediately Sync changes and not have to wait for the folder_rescan_interval to trigger. On OS's which don't provide these system level notifications, Sync has no way of knowing when a file changes other than to rescan and check for itself, and therefore the "folder_rescan_interval" is a fallback or "fail-safe" if you will, which forces Sync to rescan every folder it's monitoring on a recurring interval to see if anything's changed since its last scan. Therefore, If you're using an OS which generates real-time OS notifications when the file system changes, you can leave folder_rescan_interval at its default setting and your files will still sync in real-time. If your OS doesn't generate real-time OS notifications when the file system changes, then Sync will rely on these recurring folder rescans to detect changes, and therefore you may wish to shorten this interval. However, be aware that each folder rescan consumes CPU cycles and increases disk access, so don't set it too low, otherwise your disk risks being constantly thrashed.

It's the same on all devices, not just Windows Phones - you can only change the device name once, after which it becomes fixed and cannot be changed again (short of uninstalling/reinstalling the application). This is because the Device Name, once set, forms part of the Certificate Fingerprint for Sync on that device.

Indeed it should! I believe it's a bug in the latest 2.0 alpha builds - if you have two linked devices set to "Available" (rather than "Connected") and you add a folder to one, if you then try to connect the corresponding folder that appears on the other device and specify a non-empty target folder for it, the folder doesn't "connect" (and doesn't tell you why either). The expected behavior is that Sync should instead warn you that you've selected an non-empty folder and ask if you wish to proceed or not.

Not if when you add a new device you set it's default behavior to "Available" instead of "Connected" - that way you can select a different location for each share you subsequently "connect"

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

Your crash is most likely due to having installed both x86 and x64 builds on your device. You'd be best to uninstall both copies of Sync from your system, and also manually remove the settings.dat and settings.dat.old files from %appdata%/Roaming/BitTorrent Sync folder, then perform a fresh install of either the x86 or x64 version of Sync. Reinstalling alone without also removing the settings.dat and settings.dat.old files can cause problems when switching between x86/x64 versions, so make sure you also remove this folder. If the above doesn't resolve your issue, please try the above again, but this time remove the entire %appdata%/Roaming/BitTorrent Sync folder before reinstalling. Note: Removing the %appdata%/Roaming/BitTorrent Sync folder will mean that any shares you'd previously had defined in any earlier version of Sync you were previously running, will need setting up again, which is why in the first instance, just try deleting the settings.dat and settings.dat.old files from this folder. If you want a completely "fresh" install though, consider deleting the entire %appdata%/Roaming/BitTorrent Sync folder first.

At present, unfortunately the Sync API isn't available on mobile platforms. However, the developers are aware of the interest in extending the API to mobile platforms as well.

A number of users have experienced various "out of sync" issues recently. An experimental build is available which may possible resolve this issue for you. For more information, please see this post.

Not sure if you mean "threads" or if you actually mean "simultaneous connections/transfers"? Assuming it's the latter, the number of connections used to transfer each file depends upon the size of the file being transferred. For larger files, the data is "chunked" and transmitted via 4 simultaneous connections from what I recall instead of a single connection for smaller files. Therefore, you should notice better performance when syncing larger files over smaller files. This "4 simultaneous connections" setting is currently not user-definable. If you're referring to "threads", Sync is already multi-threaded - i.e. the UI runs in a separate thread to the actual Sync engine.