Disappointed Cat

In short: Yes. Syncronization is based on the torrent technology so the clients send chunks not files. If I remember correctly these chunks are 4MB so if your file is bigger than 4 MB and it doesn't transfers in a few seconds then other peers will help out. BTW supposedly Dropbox uses 4MB chunks too. What is it about this number? Edit: I just realized you're talking about multi-WAN. With one PC this is not possible until you can bind btsync to an IP or interface or somehow balance connections, but if you virtualize another one or if you have two PCs at home then I think so. Why haven't you tried it out?

I have nothing on that. It's not a threat if you pay attention to never use it. Also it'd be great if the client would log failed attempts so we can hook it up with fail2ban.

Try https://your.host.com:8888. Don't ever use the port 443 manually.

Thanks for the tip. I got it working. Any ideas on disabling the HTTP version? I can't filter the usual ports here.

Is there a way to change the certificate used by the webui? Is it hardcoded into the binary? I don't mind if it generates it's own but I wan't it to be singned by my root CA. I'm also interested in the inner workings of the webui. For example I assume it loads the files from the webui.zip and runs a micro webserver. Can I change things in the zip file and will it be overridden on restart or an update? Also a small feature request: It would be nice if there'd be an option to force HTTPS and using a hash instead of clear text for passwords but I'm sure this was mentioned before.

The client checks for changes every 10 minutes and propagates them if any. This cannot be configured yet. There is "immediate" triggering but sometimes it misses. I don't know how it hooks onto the file system but I never had a problem with it - not even if I edit/add files via a Samba share.

I did a little test run just now and I had no conflicts - without changing the ignore list. I only see the danger in concurrent writes. That would mess it up; but also in normal shares.

I'm syncing the My Pictures folder without any problems. If you select a folder in the file explorer it'll resolve to the real path. PS: This is Win8, they may have fixed a "few" things. Try to set it to C:\Users\blah\Pictures.

I meant ignoring *.!sync files everywhere. I don't see how it would cause collisions this way.

If these files are not ignored by default, then putting them on the ignore list wouldn't solve the problem?

I've read somewhere (probably the security thread, by kos) that they use sha256 to hash the secrets and that 32 alpha-num characters are sufficient to genereate the entire keyspace. So in my book there's gonna be a collision for every 32+ char long secrets. I've generated my own 48 char long keys (384 bits) just because I can but I don't think it's doing me any extra. (fix me)

Only with `mount --bind` and creating "sub-shares". But there might be conflicts, I haven't thoroughly tested it and I'm sure there's a reason why it's not possible to create sub-shares properly. I posted in the whislist for real sub-shares, I hope they'll implement it.

Make sure that the .SyncID files are owned by the user running btsync. Same thing happend here when I tried to continue syncing a directory that was synced as root first.

When I didn't have the same ignore list everywhere, one peer reported that the ignored folder is empty and deleted everything from the one that was suppose to have the ignored files. I guess it works with files.

Only LAN sync and known hosts are enabled for all shares on this computer since day one. I restarted many times (even the computer) since.

I see, thanks for clearing that up. Can i disable it somehow? I have no use for it on this isolated computer and it could use PEX with the server if it has to and ofc LAN sync. I tried to create a firewall rule that only allows connections in my subnet for btsync.exe, but it doesn't even care about it. BTW: On linux I only opened a port for the client itself, not for the webui, still i can access it, how is that?

I attached an example. 172.30.20.1 at the end is my router and there's is no BTSync on it or anything other than a factory Belkin firmware Edit: I'm able to reproduce this by restarting the client. Then in a few minutes they're closed.

You should have the same .SyncIgnore on every computer. I don't know why it's not sycnd. And restart the clients because it doesn't applies to already indexed files otherwise.

On my desktop I only enabled LAN search and known hosts because it's behind a firewall and bridged through my home server which also runs BTSync. So there is no point for it to go and try to see the world. I want it to be a LAN only peer. I sometimes notice that it opens dozens of UDP connections to random IPs then they're closed in a minute. Again, there is no DHT enabled, neither the tracker. And these connections resemble DHT. So what are they? I see an always open multicast connection to 239.192.0.0, that ought to be the LAN sync. I don't think this gets past my router, but is it possible? And even if it is why would I get connections from around the world? Can we get some insight to how it all works?

I'm not sure whether this can be done without conflicts, but it would be great if there'd be an option to create shares inside shares. For example I snyc my Works folder which contains all my projects but I might need to sync just one project folder with someone. It does sound like selective snyc but I don't want the other peers getting access to everything.

It could be useful and probably easy to implement if we could manually pause shares from syncing.

Because it's the same location. Why? For power and internet outages and God forbid something should happen to the house. The extra bandwith is also worth mentioning. Of course I'm not working with mission critical data so this would just be a little extra, not a must have.

By default the pid file is in the .sync directory in your user home dir. I recommend you keep the config file, and all the automatically created stuff in one folder (i.e. the .sync). BTW you don't need the pid file to start and stop the script. It's for the status command to check if it's running. That could be improved a bit and then a restart command would be pretty simple too.

Why not just set it up on the NAS servers?

I hope it does check the .SyncID, because if not, then a hard drive crash can make it delete everything in the swarm.