RomanZ

@nomarky You can do that in next way: desktop - add music folder with RW secret laptop - add music folder with same RW secret media PC - add music folder with corresponding RO secret In this case desktop and laptop will sync their music to media PC without taking anything from there. Also, by default they would not overwrite anything with the same filename and different content. Though, desktop and laptop are going to merge their music folders - as they have both the same RW secret. If you want to avoid that and keep desktop and laptop music folders separate - you have to make 2 different secrets, one for desktop and one for laptop. Then you'll need to add 2 separate folders on media PC with corresponding RW secrets. You can't sync 2 separate folders from different PCs into one folder on 3rd computer.

Tito, Discovery of other devices We are in progress, will let you know if issue replicates in our lab or we need some debug info from you. Priority implementation Not actually. The only one thing I can think of is using selective sync (it is available in API) - then you can prioritize your transfers on files level. ** Advanced logging feature ** API provides no logging, while Sync produces a debug log itself. You can take a peek here on how to turn it on. Generally, this log is intended for development and issue analysis, so no documentation available for it or planned. But log is stored in human-readable format, so you probably can sieve couple of message types you need to monitor.

@Magnetic_dud Well, it depends on what do you mean under "ports closed". Majority of firewalls by default close only incoming connections. If incoming connections are closed on both peers they won't be able to establish a direct connection - and they'll try to connect thru relay server (yes, BitTorrent server) which is rather slow and is indicated with "cloud" icon in devices tab. If any of 2 peers has incoming connections allowed - peers will make a direct connection.

@Narfus BTSync for Linux stores DBs and all app-related data in "storage" folder. Its location is either configured in config file or (if you run BTSync without config) - in hidden folder ".sync" in the same directory where binary resides.

Thanks for pinpointing it, we'll fix it.

@delegatevoid The correct value is encryption and it is the same in documentation. Please let me know if it is documented in a wrong way somewhere - we'll fix it. Also, the "type" parameter is taken only if you are generating a new secret. If you supply API some key - it will ignore the type and get it from the key you fed. If the key can encrypt-decrypt data - API automatically will give you Encryption key as well.

@Journeyman There might be some issues/bugs, but the idea was there from the very beginning: if the relative location of the file as well as hashsum is the same - do not transfer it.

@jwruffin It might be either your ISP issue (some of ISPs are throttling bittorrent traffic) or BTSync issue. I suggest following the topic about inconsistent speed. We are preparing a tool intended to debug and find bottlenecks - I'll publish more information as soon as it is ready in the topic I mentioned.

@dms2013 Right. Just to make sure - MD5 is 602281a7f1b9c0e190b086f6280ddf5c

@Titokhan Regarding your issues: Discovery of other devices I would like to test it in our lab. Do I understand correctly that your devices are using ad-hoc wifi networks to communicate each other and while mobile phones work fine - BTSync on laptops does not detect other devices in ad-hoc network? Priority implementation Already on the Wishlist. Cannot share ETA for now, though - definitely not upcoming 1.4 release. API related I suggest taking peek into this topic.

@dms2013 I'm working to provide a constant upload of fresh Android APKs on syncapp.bittorrent.com server.

@the_wizard91 The files are not going to be removed. Starting from version 1.2 BTSync understands when the whole media is removed and won't delete files from other peers. However, if the PC with Ext HDD is only one which has the data - it need to be connected to transfer data to your employer. If you have another peer with the same secret, then Ext HDD is not necessary - this another peer can seed the data.

@Devonavar Thank you for the feedback. We are implementing rather big changes and the issue with xattrs is going to be fixed in 1.4 release. Mac <-> Linux sync is going to be smooth and quick.

@datroubler Not actually. It was a known issue that it is not possible to change the secret in WebUI and fix was planned in the new WebUI.

@frater, New WebUI is present on both x86 and x64 platforms. Also, volume units are applied correctly in my lab - so if you share the circumstances when they start being displayed in bytes, I'll appreciate. As for replacement - it is surprising. The "webui.zip" is not open for usage by BTSync. Why do you want to delete it? Why not just update the binary?

Martin, BTSync uses umask for the files and folders it creates. So you can adjust umask for the user running btsync process.

@datroubler It is possible in latest version of BTSync 1.3.105. Open folder properties, advanced tab, update secret button.

@RFinn Unfortunately there is no such functionality in BTSync now. It was mentioned in the Feature Request forum once or twice, but is not implemented yet. So, for now the batch moving files out of sync folder looks to be the most optimal solution.

@cemjack It is not truncated. If secret length is more than 40 symbols, it is converted from Base64 to binary format and used as a custom secret. However, the secret of length of 33 with no matching one of control secrets as a first letter (capital A-F and R) is invalid - and you should get an error message box. Also, what do you mean under "it works on other machine"? Do you mean that you BTSync just accepts it? Or you mean that it points to the same share as 60-symbols key?

@mikelee The second log shows a bunch of SyncDb: failed to execute query to save file info - 1lines. The SQLite error code "1" states "SQL error or missing database". I suspect that something really wrong happened to your DB. I suggest removing share from BTSync and re-adding it again (this will re-create the DB for the share).

@Turoab It is not supported for mobile apps due to limited storage space. .SyncArchive exists only for Desktop versions of BTSync.

@b0rman Or use the API to control sync.

Steel, I could only advise you sharing a read-only folders. In this case once someone deletes a file, it won't be deleted from your PC. Deleted files won't be re-downloaded automatically. Also, they can re-download all the deleted files with enabling "Overwrite" option in folder properties, but this can be done with the granularity of whole folder, not the file. They won't be able to share their files to you, though.

@JimmyTheSaint Our devs are working on it. Fix is very likely to appear in 1.4.

@A3414896, Sorry for delay. Here is the answer to your question. - The term "Personal use" is not related to the equipment used to run BTSync, but more to the purpose. - If you transfer your personal data - it is personal. If you use it to transfer your company data, or use BTSync to improve your job effectiveness, it is going to be a enterprise use, not a personal. As they say in Russia, "И года не прошло" Please note, if you need any more clarifications - legal questions always take a while.