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").

I'm pretty sure it's the tracker communications, because I see the IP address of another one of the computers I'm syncing between in the response packet. The format also looks like the tracker response packet. But still weird because I disabled the tracker option.

Hi, I noticed my btsync was communicating with 54.225.92.50. I have disabled tracker, relay server, DHT, and LAN search, but it's still sending and receiving packets from this server that I assume is operated by BitTorrent. I also checked tcpdump and the packets are larger than what I'd expect from the auto-update script. Was just wondering what this could possibly be. Edit: I disabled check for updates and it's still sending/receiving packets to/from the server. Specifically, the UDP packets are coming from and going to 54.225.92.50 UDP port 3000. *** EDIT TWO: a closer inspection of the packet reveals that the server knows all of the peers where I have set up btsync, even though each one has all of the tracker, relay, etc. services disabled! Based on the protocol it also appears that 54.225.92.50 is the tracker server, which is a bit reassuring. But this is still very strange, how can the server know this when I've set it up to not give any information to any external server (and I double checked, tracker and all the rest are indeed disabled)??

Ah, you're right, I guess it doesn't matter. Still, interesting to see what other providers that _do_ ban P2P or BitTorrent-related software (although it seems like there aren't a lot of them that flat out ban) will do with Sync.

Hm, there was a comment on LowEndTalk (a forum frequented by many VPS providers, as well as users) about this: http://www.lowendtal...#Comment_259575 You have an interesting point, I submitted a ticket to BuyVM (I have one VPS, non-storage, with them) and will see what they say.

> You can PROBABLY buy a basic VPS with 100GB HDD data for $100/year, not really looked into it but yeah. http://buyvm.net has a 250 GB VPS for $7.00 per month, that's $84.00 a year. I'm actually pretty surprised this is cheaper than DropBox, considering you can do other things with a VPS (it only has one core and 256 MB RAM, but still usable for, say, web hosting).

> I did mention the 'real time' folder watch in the latter half of my post. It also is able to detect changes immediately on Windows (inotify is used on Linux, not sure what library is used for Windows). The only one that isn't supported is OS X.

It's possible that the renaming detection only works on certain operating systems (this assumes that it's based on events, like those from inotify; it may be (arguably) more robust and compare file hashes/modification times I guess). Edit: oh, if the modified file also works then that probably means the renaming detection doesn't rely on filesystem change events.

> Can I choose what directories are synchronized on a particular PC? Yes, the directories are configurable. > Are incomplete parts of a file keep spreading when a 'master' PC holding this file is offline? There's is no master computer, so yes. The protocol is exclusively distributed, where the file with the latest timestamp "wins". > Can BTS synchronize folders from many sources at once? It doesn't support version control; if two sources edit the same file, then the later timestamp overwrites the first (although the first can go to a trash folder). But if they are editing different files or at different times, then yes, by default all nodes have read+write access (read-only access is also possible). > Does BTS use incompletely synchronized folders for replication? (I have a folder, but removed some files: Can a new PC use this folder to synchronize files I have?) Not sure exactly what you mean. If you are synchronizing two different folders on two machines, then the folders will be merged; files with the same name (if I understand correctly) will conflict, and the one with later timestamp overwrites the first.

Just pointing this out, it's also possible to configure directly without using the web UI by creating a configuration file (./btsync --dump-sample-config). Personally found this easier to set up.

If I understand correctly, it'll merge the folders and, on conflicts, take the file with the more recent modification time.