RomanZ

@Lightning Understood and managed to reproduce. Thanks for report.

@eldadh Try putting "external_port" in the config file to the same place where you put all the advanced preferences.

@Journeyman BTSync does not rely only on mtime when syncing files. It also checks the hash of the file - and if it hasn't been changed, no sync will occur - it will just adjust mtimes.

All, We've reproduced issue in the lab. Thanks for reporting - we'll fix it in next major version.

@incoherency There is a workaround for that. Share a read-only secret to your android device. Then, removal of the file won't lead to its removal from other peers.

@gabor I'm not sure what carbon back up is actually backing up, but there is a built-in function to backup Sync settings in Android version of Sync. It should backup your secrets as well.

@andrewufrank The error you show indicates that BTSync failed to save necessary data to the DB with error code "5" which can be decoded as "The database file is locked". It can happen if either same DB file is used by other instance of BTSync (or any other application?) or if BTSync does not have access to the file. Any other errors that pop up in the log? Also, what sort of functional loss do you experience?

@AntonK BTSync was designed as per-user application and stores data based on user logged in. Currently there is no setting allowing to store service data. As for idea to store data within the folder - some of applications do not like when additional data is stored in their folder, and we've got a strictly opposite proposal - to remove all service data from the sync folder. I suggest trying to run BTSync with /config parameter and config file: it allows to configure location of storage directory.

@PacketMan Currently BTSync does not support PS3: it runs a clone of FreeBSD on a clone of PowerPC CPU (BTSync supports either FreeBSD on intel CPU OR Linux - on PPC). We did not plan to add it, but I still suggest noting your request in Feature Requests forum: we periodically review wishes from Feature Requests and implement them.

@JimKnopf BTSync does not do any load-balancing. Maybe in future we'll do some load-balancing adjustments, but now the traffic goes as fast as it can In your post you correlate the upload bandwidth to the fact how quickly the peer gets data. Does it correlate in some way with download bandwidth? It actually should have more influence.

@PacketMan Just finished the test in my lab - it works. I suggest you dropping me your config file so I can check what is wrong with it. Glad to hear it works for you now!

Hi all, Your comments are heard and going to be addressed. We plan to add SSL for WebUI soon, as well as working on secure way to transfer secrets.

@eddieparker It depends on what is blocked. If outgoing traffic to port 3000 and other random ports are allowed AND other peer(s) can map ports with UPnP/PMP for NATs the peers should be able to connect. @proactiveservices The connection thru relay server is extremely slow. Also, it goes thru port 3000 and if FW blocks outgoing connection to, say, all non-web ports - it won't work.

@cyberto, A good point for Feature Requests forum.

@stalk I guess you have a data which can be well compressed, right? BTSync does not compress data on the fly. It just splits data to blocks, hashes it encrypts and transmits. @andi The instructions link you mentioned is correct. You need to make a debug.txt file in BTSync storage containing "FFFF" and that will force BTSync for full debug output into sync.log. I checked this functionality for 1.3.105 on Linux Mint - it works just fine. As for the "Failed to get mtime" - this usually indicates permissions issue. BTSync could not access these files. It should not block indexing the rest of files / folders though. What do you see at the end of day? Some of files / folders are not indexed or some other symptoms?

All, Thanks for the feedback. @Lightning Thanks for the bug report - we'll fix it. Not sure what do you mean regarding the path - both in 1.3.94 and 1.3.105 it shows full path including the dir name. Could you please elaborate / show a screenshots? @b0rman Well, its a good point to be mentioned in Feature Requests forum. @andi Your issue does not look like to be bound to 1.3.105 release as it had only WebUI changed as well as couple of crashes fixed. I suggest collecting full debug logs with log size limitation of ~200Mb and sending them to me for analysis to syncapp@bittorrent.com.

@Dr Jeff Do I understand correctly that in your case these "hidden-after-sync" files are also visible in terminal?

@mikeyF Try using a relative path with sync folder as a root

Sync uses next ports and protocols to function: Discovery of tracker and relay IPs: HTTP port 80 to config.usyncapp.com (via DNS name) (http://config.usyncapp.com/sync.config)Connecting to the tracker server for automatic peer discovery: TCP and UDP port 3000 to t.usyncapp.com (via direct IP, 54.225.100.8, 54.225.196.38, 54.225.92.50)Connecting to relay server to transfer data if direct connection is not possible: TCP and UDP port 3000 to r.usyncapp.com (via direct IP, 67.215.231.242, 67.215.229.106)Direct connection to transfer data: TCP and UDP port <configured_by_user> to remote peerPeers discovery in LAN Multicast UDP 239.252.0.0 over port 3838Automatic ports mapping over UPnP and NAT-PMP UDP multicast to 293.255.255.250 port 1900 UDP unicast to default gateway port 5351

@RNAOMDCOLECLTOINOFLERTTES Thanks for the logs and packet capture, seems I've found the answer what is happening: you have a DHT turned on. All these "suspicious peers" are actually part of DHT network. I suggest to do the following: 1. Make sure DHT is off for all your shares on all peers. 2. Change listening ports on all peers.

@arynhard Actually I don's see other alternatives.

@Afrosheen Sync officially available in Amazon store for Amazon Kindle Fire. As for the other e-readers - if they are running Linux and have one of supported architectures - you can try bringing binary there and running it.

@ptomblin The amount of memory consumed depends on amount of files and folders you have. Can you compare it to the amount of memory consumed on other peers syncing same folders? If it is significantly more and keeps growing - seems you've encountered a memory leak (in this case we'll need a core dump of btsync process).

@Native Advertisement Let'd continue to communicate in ticket system to resolve your issues.

@mikeyF Well... why did you sent the key then ? Anyway, I have some good news for you. 1. Your API key is okay and not revoked. 2. Your config with API key worked just fine in my environment. 3. Thanks to one of our support engineer (Helen) I have a good guess that I know why it is not working for you. It is very likely that you are running btsync.exe right from the "program files" folder - which is protected by UAC. While your config tells it to put all the data directly into the same folder is binary - OS prevents that and btsync simply can't run further. So - either move your binary from the program files, or just put your storage folder in some other location. Here is a sample config which is going to work: { "storage_path" : "C:\\MyAPIStorage", "use_gui" : true, "webui" : { "listen" : "127.0.0.1:8888", //"login" : "<someusername>", //"password" : "<somepassword>", "api_key" : "<your_API_key" }} 3 small notes: 1. MyAPIStorage folder must exist 2. When putting paths for Windows OS - use backslashes as component delimiters 3. As backslash is a special character in JSON - you have to escape it (put twice).