GreatMarko

Windows RT is somewhat limited, in that you can't natively install and run non-Microsoft apps - including Sync. But in answer to your general question, yes, you can install & run Sync on other Windows Tablets (Windows 7, Windows 8, etc) - just not easily on RT My advice, if you're looking for a Windows tablet, is don't purchase a Windows RT based one. Take a look at something like the new Dell Venue 8 Pro - a Windows tablet that runs Windows 8.1 Pro for under £250 (~$400 USD)

You're not missing anything - this ability isn't currently present in Sync. You'll find the Wishlist thread here, so feel free to post your suggestion there. As a potential workaround, you could use scheduled tasks to only have Sync running at certain times of the day - whilst this wouldn't "limit" bandwidth, it would at least allow you to choose at which times syncing takes place.

Yes, by disabling the per-folder "Store deleted files in SyncArchive" setting In relation to advanced settings: disk_low_priority Concede resources to other applications/reduce hard drive thrashing Default value: True rate_limit_local_peers Reduce the amount of traffic on the local network (i.e. reduce pings, multicasting, etc) Default value: False folder_rescan_interval How often folders should be automatically rescanned (in addition to detection of real-time changes) Default value: 600 (seconds) sync_max_time_diff How closely synced the system clocks on your devices should be. If the system clock on a device is out by a value greater than this setting, Sync will not take place Default value: 600 (seconds) lan_encrypt_data Encrypt all Sync traffic on local network. Disabling this may give a slight increase in speed when syncing locally. Note: This des not affect syncing over the Internet/WAN Default value: true sync_trash_ttl How long files should persist in SyncArchive before being automatically removed Default value: 30 (days) lan_use_tcp Use TCP for local connections (instead of UDP) Default value: False max_file_size_diff_for_patching Changes to files that are greater than this value will cause the entire file to be transferred, rather than just the part that's changed Default value: 1000 (MB) max_file_size_for_versioning Files that are greater than this size will not be "versioned" - i.e. stored in SyncArchive Default value: 1000 (MB) send_buf_size The size of data held in memory before being sent Default value: 5 (MB) recv_buf_size The size of received data held in memory before being written to disk Default value: 5 (MB)

Yes - there is no problem with this setup, provided your server is online and running Sync No - In order to receive large files faster, Sync will attempt to obtain different data "chunks" of the same file from different peers - so you're not necessarily uploading the same file multiple times to different peers - just "chunks" of it to other peers who will in turn "share" those chunks with other receiving peers to speed up overall dissemination of the file

Yes, I should have been more clear - I was referring to a folder's initial indexing. Obviously, Sync rescans the folder each time you start sync in order to detect any changes to files that were made whilst Sync wasn't running. But these subsequent "rescans" should be very quick in comparison to initial folder indexing, as the entire index isn't rebuilt from scratched each time, just "refreshed". Sent from my computer using my keyboard

No, whilst Sync remains in "beta" not every build is made available through the "Check for updates" button - you can grab 1.2.73 instead through this pinned thread

Also, remember that Sync can't transfer files when they are open/locked/in use by other applications - such as the case of .xls files open in Microsoft Excel. Closing Excel should then allow your .xls files to transfer.

It's important to let Sync finish indexing your folders before powering off your device. If indexing is incomplete/interrupted, whilst this won't do any harm, it will mean that the next time you start your computer (and Sync), Sync will attempt to re-index the folder(s) again. Once you've allowed Sync to fully index your 150GB folder, it shouldn't need to re-index it again upon subsequent runs.

Sync cannot sync files when they are open/locked/in use by other applications. Closing files in their associated applications, or closing those applications themselves will allow Sync to then transfer the files. Also, check the exclusion rules in your .SyncIgnore files to make sure the files you're trying to sync aren't being excluded.

As I said in my original reply, there has been a high demand for API keys. In addition, when you apply for a key, you're also asked to provide details of how you intend to use the API. With this in mind, and given that the API is very new and still undergoing testing/development, it is highly likely that at present, the release of API keys is being somewhat controlled and that not everyone who applies will be assigned an API key during this testing/development phase. That's not to say you'll never get an API key - if you're on the list, you're on the list, and the release of more API keys will almost certainly increase as the API develops and becomes more "solid". The bottom line is: If you've applied for an API key, you're on the list, and you'll need to be patient - it may be a while before you're assigned your own API key.Signing up multiple times will likely not get you a key any quickerPosting back in the forums every other day complaining you've still not got a key won't get you one any quicker!

Probably caused by your Win8 device "crashing" mid transfer. Try stopping Sync on both devices, removing any .!Sync files, and starting Sync again as it may resolve your issue. If Sync won't even start on your Win8 device, a reinstall of Sync may be required as setting/config files may have been corrupted when your system crashed. If your Win8 devices "keeps crashing", you'd be wise to investigate and resolve the root cause of this to prevent further damage to your programs/files

Sync's aim is to sync your files as fast as possible - if you're syncing a large file between multiple devices, Sync will attempt to get "chunks" of data from all available sources on your various devices where possible, however, it will prioritize this based on how quickly each device can deliver the data. If one device's network connection is - for whatever reason - slower than other devices, all data "chunks" may be received from other devices before the "slow" device has been able to send its chunk(s)

Are your devices connected "Directly" in Sync, or "Indirectly"? (See "What do the device icons mean" in the Unofficial FAQ for how to determine this) If they are connected "Indirectly" your transfer speed won't be anywhere near fast as "Direct" connections - so that would be the first thing to check! Also, I assume you're not limiting the upload/download rate settings in Sync? Finally, I assume your ISP doesn't enforce any form of "Traffic Management" that may be slowing down your download rates?

Unfortunately not - it's all or nothing! The only workaround would be to remove your other folders from Sync (after noting down their secrets so you can add them back), leaving the one folder you're interested in. That way only that folder's activity will be logged. Not ideal, but a potential workaround. However, if your Sync is stuck in a "loop" on one particular folder, I'd suggest trying the following first: 1) Stop Sync on all your devices 2) In the folder in question, check for and delete any .!Sync, .SyncPart, .SyncTemp or .SyncOLD files 3) Restart Sync (The above steps should allow Sync to retransfer any "stuck" files) If this doesn't solve your issue, then: 4) Make a note of the folder's secret 5) Remove the folder from Sync 6) Remove the .SyncID file from the folder itself (note: this may be a hidden file) 7) Add the folder back to Sync with it's original Secret (The above steps should cause Sync to freshly re-index the folder) If none of these things resolve your issue, then I'm afraid you will likely need to "send in the logs"

Not at preset - there is currently no "selective sync" interface for Desktop editions of Sync

I agree with you, however, as Sync is currently still in a "beta" phase, and new test builds are released frequently, not every beta build is pushed via auto-update - This will change once Sync leaves beta and the auto-update feature is fully "turned on". I also agree that once auto-update is fully "turned on", that it would be great if Sync could auto-update itself without any user interaction - this makes a lot of sense on head-less servers! Personally, the way I hope to see this working in the future would be that if you're sharing a folder between a number of devices, one of which is running a newer version of Sync, then as part of the data transfer, that newer version of Sync will automatically and securely propagate and install on all the devices you're sharing between - to ensure that all your devices will always be running identical versions of Sync!

Yep, I've seen this same error too on a couple of occasions on 1.2.73 when sharing between full-access devices, so the issue isn't just limited to "read-only" shares. From what I can determine, the files are transferring as .SyncPart, .SyncTemp, or SyncOLD files, but then not being correctly renamed to removed the .SyncPart/.SyncTemp/.SyndOLD. The "PostDownload: Cannot create a file..." error is then thrown and the result is the original file (i.e. the "older" version that should be being updated/replaced) is still present along with a corresponding .SyncPart/.SyncTemp/.SyncOLD file. My "workaround" was to delete any .SyncPart, .SyncTemp, or .SyncOLD files, as well as the original file on the receiving device - this causes Sync to re-transfer the newer/updated file to the device.

You'll need to add it to your config file.

Yes - Go to "Preferences" and untick the "Show notifications for completed downloads" option.

Remember that Sync is a file synchronization tool - it's not designed for synchronizing arbitrary "settings" or "contacts", unless these are stored in a physical (and accessible) file.

No No Right away!

If you have one "master" host and several "read only" hosts, the "read only" hosts will also be able to transfer data between themselves to speed up overall dissemination of files from the master to all "read only" hosts: ..just a little illustrative graphic I cobbled together!

Not at present, but it has been suggested once before in the Wishlist thread, so feel free to suggest it there again!

If removing the folder and re-adding it didn't work, it may be that the folder's .SyncID file is corrupt/has been damaged. Remove the folder from Sync again, then delete the hidden .SyncID file within that folder, then add the folder back to Sync again with the original secret. Sync will generate a new .SyncID file in the folder, which should cause Sync to reindex the folder correctly.

I don't believe so - you have to list individual IP addresses (or hostnames), rather than IP ranges