perennate

Yes, it is running; although I tried cp and mv from another file to the "filename" and it worked. "touch filename" also completed successfully. "filename" doesn't actually even exist in the sync folder, because bittorrent sync renamed it to "filename.!sync". I'll try that later.

Well now it looks like syncing from single peer doesn't work, but I still can't figure out what's causing this. The two errors in the log are "cannot open filename.!sync" and "filename - writetodisk: text file busy". But I can read filename.!sync and I can write to filename.

I have a problem where I'm getting "WriteToDisk: Text file busy", which happens after it connects to multiple peers for the same file. This is also an executable file that is being run by multiple programs, which could cause a problem with the file being busy; yet, the file is renamed "filename.!sync" and the original file doesn't appear to be busy. Additionally, it works when there's only one peer, so that leads me to believe it's a problem only when there's multiple peers that it's syncing from. Still, that seems kind of weird considering that btsync has been tested a lot already.

Sidenote on versioning: if it's implemented it should be optional so that people who don't want versioning don't have multiple files taking up space. > Ability to revoke a secret key (use case: secret key is leaked) As I understand it, the secret key is part of what's used to encrypt contents while they're being transferred. So there's no way to revoke a secret key: if an attacker has both the data transferred and the secret key, then there's no way to go back and take away the secret key to prevent the attacker from decrypting the data, because the data has already been transferred. Also, if you just want to update the secret key and there hasn't been any attacker monitoring your traffic, then all you have to do is switch the secret key in configuration. Edit: oh, and please add ability to set read only secret in the configuration file, there doesn't seem to be such a feature yet.

We were talking about VPS or other hosting providers, not ISP's, so none of what you wrote applies. Some hosting providers don't permit BitTorrent on their servers; they rarely have strict blocking that prevents certain ports, but they do have monitoring, and if they catch you violating their acceptable use policy then they'll terminate your service. It's a reasonable thing to ban completely, if the hosting provider doesn't want to deal with abuse complaints to the people who do download illegal content (which is usually the majority of uses of BitTorrent on VPS).

Then whenever you want to visit a website, you'd have to wait a painful amount of time to find peers and connect to them.

Unfortunately btsync is closed source... see

I'd email syncapp@bittorrent.com if you haven't already.

Well, for now you could try connecting all of them to a few (1-5) servers, and then enabling DHT which should allow them to discover more. Anyway I think it'll take a lot more bandwidth than necessary if each instance connects to every other instance (I get constant 3 KB/s idle chatter with 10 connections). Somewhere they said they were going to release tracker eventually.

I just tried syncing a hidden directory (~/.test) specified in configuration file and it's working fine for me. If you hard code the directory in the configuration file then the web UI should be disabled, what do you mean "it doesn't show up when I start the program"? I assume you're passing the configuration filename to the btsync binary? Edit: also, there might be some problems with detecting file changes on a mounted filesystem, but the ten-minute fallback sync interval should still work.

There is an admin username and password required to authorize, that'd take a lot of tries to guess both strings correctly. Also I assume there's some antiflood to logins, but maybe not.

I wouldn't use btsync for that, you'd almost certainly run into integration issues that you can't resolve due to closed source nature of the project.

> I wonder what would happen if the tracker was compromised.. What do you mean? Like you said, the tracker only knows the SHA2 of the secret. So nothing would happen if tracker is compromised, you'd just make connections to peers that don't share your secret and then only realize that after making the connection; your IP address is publicized but not the secret itself. SHA2 in this system is designed to be public.

I think it means that the hash of the secret isn't matching with your peers. So maybe you set up another computer with incorrect secret?

I think the tracker for btsync is different from the tracker for normal BitTorrent; it's also not possible currently to specify your own. With a few iptables rules you could redirect traffic to your own IP address, and the protocol doesn't seem that complex so you could dump some packets and try to reverse engineer it if you wanted. If you can't ping one client from the other then you better fix that issue first. The clients have to be able to send/receive UDP packets from each other for btsync to be able to work (if you set the host+port in configuration, no broadcast packets need to be used, it sends UDP packets "directly").