RomanZ

@nellie4568 I would say even more. If you've lost all your RW peers, to restore encrypted data you need: a) Enc-RW key all files on Encrypted peer c) all metadata (Sync database) on Encrypted peer.

@gloupi If BTSync is transferring them - it will show the transfer speed below, trying to saturate your bandwidth. If it is not transferring files, the transfer speed would be symbolic - like 3-5kb/sec and files will switch in transfer tab really quickly, while transfer queue will be diminishing quickly.

@gloupi BTSync should identify that files are the same and do not transfer them. You have pretty big volume of data, so it will take BTSync a while to hash all of them. I suspect that process of hashing (indexing) might make you thinking that files are actually transferred. 2 things to check: 1) As Harold said - do you see actual transfer going in "Transfer" tab? 2) Is the remote dir structure and file paths are the same? Even the minor difference will force BTSync to re-transfer files.

@j2b That's correct. BTSync also distinguishes between LAN ip:port and external ip:port, so it lets tracker server know both. Not sure what do you mean under term "Firewall friendly" here, as it does not talk to any 3rd party firewall explicitly (only to built-in Windows FW). I suggest that you are talking about statefullness of the FW and the fact that FW should let incoming packets in because some packets were out from particular IP:port. Actual behavior depends on FW/NAT implementation. Some will allow incoming packets, and some not. If FW/NAT smart enough to track and compare the destination of outgoing and source of returning packets - it might block packets if IPs differ. In such case it's always safer to make port forwarding. Sorry, did not understand the question. Every instance of BTSync gets information from tracker - where are other peers with the same share. They know the internal (LAN) ip:port and external one. If subnet in LAN is the same - it will try to connect to the local port. If it is different - it will attempt to connect external port. If external port is blocked by FW or NAT - well, no direct connection is possible. Yep. Conflicts are possible as with any port forwarding. Actually, FW won't let you map same ports to 2 computers. Yes. Every instance of BTSync needs to be able to send outgoing connections / packets over TCP/UDP port 3000 (contacting tracker and relay server), port 80 (getting addresses of tracker and relay), get incoming connections to the "Listening port" (see preferences). For LAN discovery you can also add UDP port 3838.

@Dersch Some questions and things to check: 1. Which previous version you were using? 2. please execute next commands and supply me with their output: ps -eo vsz,cmdnetstat -npt43. When you restart btsync - which command do you use? how do you know that it actually does not restart? 4. Did you try to force-kill btsync (kill -9)? Thanks!

@eddieparker Can I get the debug logs to see what your btsync is actually doing all the time? Please send them to syncapp@bittorrent.com, mention this topic in the message body.

@SpikeDaPenguin BTSync is going to change files on your PC only if they were changed on remote location. That's why I proposed to share the read-only secret with your remote location. It's rather simple: when opening folder properties in Sync - you can copy "Read-only" secret and use it on remote peer. For syncignore rules please see this topic, section "How do I use "*" and "?" wildcards in .SyncIgnore files?"

@terafin Did you have a chance to mark down the time when BTSync was idle? Was it from night time till around 12:20?

@josh4trunks This error together with error code 55 indicate that OS refused to increase buffer size. It should not affect functionality, might affect performance a little bit. @gmosquera Do you see your linux box in the devices list on other peers?

Yes, this is default BTSync for iOS behavior.

@petromycon If btsync binary is simply started - it should store its data in .sync subfolder. However, if it is started with some parameters (for example, with --config) service data folder location might be changed. How do you start btsync? Do other files in .sync subfolder change?

@vasaka Did you try to add sync folder directly with full UNC path? Windows treats these 2 ways slightly differently. Also, can you please provide full version of your debug log to syncapp@bittorrent.com?

@Dersch Can you please explain why you have to reboot RPI? What happens if you do not reboot?

That will change umask for all users. If you want to change it for single user only - you need to adjust .bashrc file which is stored in home folder of designated user. This will work only if user runs bash, of course. Alternatively you can make a simple shell script which first - runs umask command, then runs btsync instead of simple btsync startup.

@Sync_lost Yep. Same issue. BTSync binds it multicast port to only one adapter (one that seats on the top).

Hi all, I confirm - there is an issue. It is going to be fixed in next 1.3 or 1.4 (whichever comes faster) release. The issue is that BTSync incorrectly indexes directory junctions in certain cases.

@SpikeDaPenguin Sync gives a latency of 10 seconds to settle down the file after last change before syncing it. Can you elaborate what is getting messed? BTW, for the backup purpose - you can use a ReadOnly key to make sure remote peer won't change your files.

@benguild Sync does not send the file if the hash did not change. However, if the file is really small - the metadata for the file (hash, change time, etc.) might be greater than file. Sync calcs the hash tree for all the files and folders and only compares the top-hash to see if folders are out of sync. If they are - it has to check where trees are different. I wonder, how many files are synced in your case and what is the average file size? Please also note, that Sync is in Beta and yet has a lot of areas for improvement.

@spYro Sometimes it happens. I'm grateful to the community that people help themselves, so I can concentrate on more complex cases

@spYro Exactly. @JimmyTheSaint Only few preferences require BTSync to be restarted (like DHT). I'm preparing a list of preferences that actually require restart - will be available with 1.4 release doc. @mrspcs & all If you still experience that issue - I'd appreciate full debug logs for it so I can take a peek and (hopefully) resolve the issue.

@timecott01 BTSync uses listening port for incoming UDP packets and TCP connections. When BTSync uses UDP - it uses the same port for outgoing data packets, but when it uses TCP - it has to pick a random outgoing port. In your configuration (2 computers sitting behind NATs trying to talk over internet) the most simple setup is to enable UPnP on your NATs and make sure it is enabled in BTSyncs. If you do not trust UPnP or can't enable it - you can make a port forwarding. In this case you need NAT to forward exactly same port as configured as "Listening" to the PC where BTSync resides. @spYro The listening port is used not only when using the tracker to find each other. In LAN discovery once PCs exchange data in Multicast packets - they will know each others listening port and connect to it. But you are right in the second part - if the Listening port is open in firewall (assuming this is stateful firewall) and mapped via NAT - BTSync should work fine.

@drjones The pictures will remain on PC if you delete them on iOS device. Please note, that due to iOS peculiarities photos won't backup automatically in background. To back them up you need to open BTSync explicitly.

@BeTheSync Great, I'm glad it works for you now. Sync Team is working hard to improve Sync and make it more simple and reliable.

@kleinveld This forum is dedicated to Bittorrent Sync. Do you mean Sync or Bittorrent Client or uTorrent client?

@rimanek We are actively working with Synology now to satisfy their application store demands for BTSync package. I cannot supply you with precise ETA, but it should be really soon.