GreatMarko

It's a really tricky issue to address, and sadly more of a limitation of operating systems than of Sync. For example, Windows would see "TEST.TXT", "test.txt", "Test.txt" (or any other variation) as being one and the same (try creating these variations in the same Windows folder - you can't!), where as Linux would see each of these as unique, individual files. Because the Windows Operating System see "TEST.TXT", "test.txt", "Test.txt" as identical, Sync on Windows would also see these as identical. It's a really difficult problem to address, and really, the best advice at the moment would be to avoid multiple files with the same name, but various cases, in the same Sync folder.

There are a whole host of technical reasons why this hasn't been implemented - the most notable is that it could lead to files/folder structures being duplicated ad infinitum - Please see this post The only real workaround at present is to setup individual syncs on each sub-folder, instead of a single sync on the parent folder. This will allow you to selectively share different sub-folders to different devices, or to sync the entire "parent" folder, you would just sync each sub-folder within to your other devices

Yes, I've previously raised this with the development team so hopefully units will be indicated in a future build, but for reference, the units for the various numeric advanced settings are as follows: folder_rescan_interval = seconds (default 600) max_file_size_diff_for_patching = Megabytes (default 1000) max_file_size_for_versioning = Megabytes (default 1000) sync_max_time_diff = seconds (default 600) sync_trash_ttl = days (default 30)

@palpable Firstly, BitTorrent Sync isn't capable of "nested shares" (Please search for the forum for more on this, as well as potential work-arounds) You're really over-complicating things by running BitTorent Sync and Synkron - i.e. running two different Sync apps in parallel - this is never going to be a good solution and inevitably leads to issues, like the race condition you're experiencing! My advice: 1) Search the forums for better workarounds to the "nested share" issue - they do exist! (i.e. set up a separate sync for each sub-folder rather than a single sync on parent folder - this then allows you to selectively sync different folders to different devices, or sync the parent folder, but then investigate using .SyncIgnore to "exclude" certain sub-folders from certain devices, or if you're familiar with them, use symlinks/folder junctions, etc) 2) Most importantly - Don't run multiple Syncronization apps at the same time - that's never a good idea and WILL cause issues!

I completely agree that BitTorrent Sync isn't primarily designed to be an archiving solution, however, just to pick up on the point about versioning - Sync does have some support for "versioning" of files within .SyncArchive. i.e. a file named "myfile.txt" that's deleted will be moved to .SyncArchive. If another file with the same name is added to the sync folder and subsequently deleted, .SyncArchive will then contain "myfile.txt" and "myfile.1.txt".... the next deletion of "myfile.txt" will add "myfile.2.txt" to .SyncArchive, and so forth. So again, whilst Sync's primary purpose isn't as a complete archiving solution, it does have some, limited, support for "versioning"

You can increase the advanced "sync_trash_ttl" setting from the default "30" to a higher value to keep files in your .SyncArchive folders for longer than 30 days!

Ok, so I don't have a Samsung Galaxy S4 specifically, but Sync can access the SD card on my Android device without issue! Are you able to try using a different SD card to help determine whether it's a problem with the card, or your device?

Please read the very first post in this thread, particularly the section "What do the device icons mean?"!

You don't specify which version of the Android app you're currently using? There were issues with power consumption in some of the earlier Android app builds - are you using the latest? (1.1.38)

Firstly, it's not currently possible to set/specify which network interface Sync uses (feel free to suggest it in the Wishlist). A potential work-around would be to disable all but the network interface you wish to use before starting Sync. Secondly, in terms of communicating on "specific IPs" - you could use the Predefined Hosts options (whilst disabling the Relay, Tracker, DHT, and Search LAN options) Thirdly, please be aware that "reverse engineering" the binaries is against the Terms of Use

1) This thread was started by kos13 - the lead member of the BitTorrent Sync team 2) The update checker is NOT broken - not every "beta" build is pushed out via auto-update 3) Please see this post

The Sync team are currently focused on Sync 1.2. There is very little difference between builds 1.1.48 - 1.1.82 (the latest build currently available to end-users), only minor bug fixes - nothing that was deemed "critical" enough to warrant pushing out a new build via auto-update to every user. Therefore if 1.1.48 is running fine for you without issue, you're not missing out an any "new features" by not running 1.1.82, and you shouldn't worry - 1.1.48 is compatible with 1.1.82. Auto-update IS working, but not every "beta" build is pushed out via auto-update. Please be patient, new builds will be pushed via auto-update as and when appropriate.

At present you can't.. the only potential "workaround" would be to enable debug logging, as this will contain info on the files Synced... however, be aware that having debug logging enabled will quickly generate very large files!!

Please read the Unofficial FAQ, particularly the section "When a file changes, does Sync transfer the entire file again, or just the part that's changed?"

192.168.0.103 will be another device on your local LAN. "52748" indicates the port being used Now, normally Sync is able to determine the device name and so replaces the IP/Port information with the device name. This usually happens within a few seconds of Sync starting. The fact that this doesn't appear to have happened in your case may indicate that the IP address of your other Sync device has literally just changed mid-Sync, leading to two entries in your device list. If this is the case, restarting Sync on your devices should resolve this. Bottom line is that 192.168.0.103 is an IP address confined to your LOCAL LAN... so I wouldn't be worried too much about it!

Please read the unofficial FAQ - it is not possible to sync between two locations on the same computer!

He said... it was a full disk!!

In all honesty, the developers are currently focused more on Sync 1.2, and I suspect given the apparent short lived appearance of 1.1.78, not enough people downloaded it and/or the potential issue(s) that seemingly led to its subsequent removal were obscure enough not warrant re-building 1.1.70 again with just a higher build number! The bottom line is that the "current" latest build publicly available is 1.1.70. If a small number of users managed to obtain 1.1.78 and this is running for them without issue, fine - but other users who don't have 1.1.78 shouldn't feel as though they're "missing out", as there were no new features with this build... and as I say, Sync 1.2 is just around the corner anyway!

There were no new features between 1.1.70 and 1.1.78, and likely only bug fixes. However, the fact that 1.1.78 isn't currently available suggests that the developers found a particular issue with it, and felt that 1.1.70 was the more stable option for users at this time.

Please see this thread

The thread you refer to was intentionally locked, it is not a bug related to the upgrade of the forums

Hmmm... the Windows version linked to from http://labs.bittorrent.com/experiments/sync.html (Direct Link: http://download-lb.utorrent.com/endpoint/btsync/os/windows/track/stable) is currently 1.1.70... not quite sure where you've got 1.1.78 from?!

There is currently no timeframe for the API. According to the developers at the start of this week "we're just about to start the discovery stage for [the Sync API] now... we don't have details or timing yet"

Yes, the broken quoting is pretty annoying! I hope there's a fix soon!

The Wishlist thread is NOT useless - yes, it's long, but the purpose of it is primarily to aid the development team, who do frequent it, and are keeping track of how often each suggestion pops up - that's why you, as a user, don't particularly need to know what's been suggested previously in that thread to be able to contribute to it, as the more recurrence a particular suggestion gets, the more the developers will see the demand for it. In summary, the developers are watching the Wishlist thread closely. Therefore suggestions for improvements/new features should still be posted in that thread (it's Pinned there for a reason!) for the time being whilst Sync remains in "beta".