Disappointed Cat

If someone is using BTSync for security and freedom of 3rd parties then why would he/she want to store the secrets on a 3rd party site? Even if you encrypt them you'll have to be able to decrypt them in order to actually share it with select users. The idea of sharing secrets is a good point but I don't think it should be done in a middle man scenario.

I see. Then I have nothing to add. BTW 266MB for 11GB is still looking weird compared to 464MB for 265GB, I guess you have a lot more small files.

My metacache (on linux) is 464MB for 265GB data. That's about 0.17%. Are you using the latest 1.0.134 version?

I'm sure it's nice but don't you think this renders the high security pointless?

I'm also using Dropbox until BTSync doesn't have an android app. The important thing to keep in mind is that you can only run Dropbox in one location or you'll end up with massive conflicts. I didn't test it with multiple locations but it only makes sense. You can also create conflicts if you edit something via Dropbox and a BTSync peer at the same time. It's also a good way to store encrypted automated backups of synced folders and make use of Dropbox's versioning too.

They are working on an API. See this thread.

I configured my public domain (home server) in all my shares' know hosts on every PCs. The tricky thing is that this domain has different DNS settings in my home network (records to local IPs). From the outside world it has a wildcard CNAME record ponting to whatever dynamic DNS service I'm using. On my laptop this setup confuses BTSync into opening connections with the public IP and the local IP at the same time. After sync the connection with the public IP closes. I think the control connection is opened with the local address and the transfer connection is opened with the public. For later transfers BTSync opens connections with the correct address.

There is no way of doing this with the BTSync app. Maybe you could experiment with advanced file permissions and take away it's ability to delete files.

Except there are close to a hundred connections periodically opened for DHT even if none of your shares has DHT enabled. These are initiated from the same source port so I think it's possible that an IDPS or a firewall policy could block it.

Use SSL for client - tracker communications. I realize that even if someone catches the hash for a share, the data is still safe but sending that hash to the tracker the attacker can get the IP addresses of all connected peers and it's open season from there.

Source code versioning tools really hate big binary files. Git will die a horrible death if you squeeze hundreds of GBs into it. Also they might not even use delta encoding for binary files so you loose a lot of space too. It was mentioned that the developers intend to implement versioning, maybe that's gonna be the next major feature. @keamas If you want WebDav you should set it up yourself. But I think you're better of with something like Ajaxplorer.

Ignore lists generally work this way - including BTSync : If there is a path separator ('/' or '\') in the line, it's matched against the relative path of the file. Otherwise one line means only a filename. So: somefile.dat matches somefile.dat in every directory ~* matches ~somefile.dat *$ matches somefile.dat$ dir/~* matches dir/~somefile.dat and asd/dir/~somefile.dat but not other/~somefile.dat and the same strictly to the current root: /dir/~*

Are you sure about this? Multicasting for some reason doesn't work between my desktop and laptop (bridge, WiFi AP, firewalls, who knows why..) but if both PCs communicate with the tracker they can find eachother. I did have to disable the relays though.

You probably used unison via SSH which has it's own locale settings. But I might be wrong and something else is causing this.

It depends on the OS. I assume your Mac is set up correctly to use UTF-8. Then you need to set the encoding of the environment to UTF-8 in your NAS too. I don't know what your NAS is running but you can do that in linux and most unix OS by putting a file in /etc/profile.d/ with the following content: export LANG='en_US.UTF-8' export LC_COLLATE='C' After creating the file either reboot or call `source /etc/profile.d/file`.

I experienced this too. But for me it only occured in shares with ignored files and never in ready-only mode. They will be fixing this in the coming versions.

Not so much an issue but what are these doing in the settings file of the windows version? e11search_list117:BitTorrent|http://www.bittorrent.com/search?client=%v&search= Mininova|http://www.mininova.org/search/?cat=0&search= e12:tracker_last86:udp://tracker.openbittorrent.com:80/announce Obviously remnants of the BitTorrent client. Anyway I think you should clean it up.

There is no mundane way of telling which files are in queue for sync.

Check out the Devices tab. If it says Synced on <date> then it's done, otherwise the status will show how much data needs to be uploaded and/or downloaded. You can see the same thing on the linux webUI.

That's pretty much useless in my case. The whole point here is not having to mess around with tens of thousands of files. Anyway, it wouldn't even work because first you have to download the files with the original paths which you can't do with windows explorer, neither with BTSync if you don't use UNC. Not mention I would end up with Foobar2000 monitoring things twice.

I think 255 bytes per path level - at least on Debian based distros. So you can't have longer filenames than that, but each directory can also have a long name. Have you tried syncing a linux client and a windows client which has these "short" links or just windows to windows? Because they do get synced between linux and windows but maybe another windows client would just say "Got it, chill". You're right. The connection which I misunderstood is that Win API functions that have unicode versions support UNC. Link.

Make .SyncIgnore apply to remote paths too. That way it could serve as an exclude list and selective sync. They're not synced so I don't see why not. Two birds, one stone. Sure we could end up with a bunch of uncomplete shares but that shouldn't be a probem with torrent style sharing.

We all know that the Win32 API is limited to 255 byte length path names. Same mentality as "640K ought to be enough for anybody." NTFS however does not have this limitation and for quite a while now windows supports UNC paths by prefixing the path with '\\?\'. But there are also limitations: relative paths don't work with UNC. My music library has a few really long paths which I can't/won't rename so I had to try this out with BTSync. So I added my library this way, waited for the indexing for a lifetime and there, it works. However Windows also creates magical shortened paths for paths that are too long, for example ASDASD~1. These get synced too, so I added filters to .SyncIgnore. This way the length limitation is gone, and programs can also handle them with the help of these short paths. But even though the peers synced successfully the apps always show there is still some GBs of data to transfer. Is it safe to rely on BTSync working with UNC paths? The only problem I encountered is the syncing of these shortened paths. In my case adding an exception for *~1 solves this but with some wierd paths or conflicting short names this fails. Also there seems to be a bug when the are ignored files, the app shows on the devices tab that is has x GB to upload but it's actually synced. I readded the share in read-only mode and this problem goes away too. Also read-only mode seems to require a lot less (like half) resources.

A tiny correction: The client will recreate the empty .SyncTrash folders even without the Delete to Trash option. Noting serious but still, you cannot eliminate those pesky trash folders for good.

Turn off disk_low_priority and lan_encrypt_data, and turn on lan_use_tcp (advanced settings). This helped me to achive 40-50 MB/s on big enough files, before this I could only squeeze out 6-9 MB/s. I can barely beat this with Samba, but for small files Samba is a lot faster of course. For small files I found that syncing with 3 or more computers is considerably faster because you can have more parallel transfers and the network is usually not the bottleneck even if you're bridging like me. Also maintaining a gbit network does require a lot of resources. Maybe RPi can't handle it. Run some tests with iperf or nutcp. If it's painfuly slow but the network is good it might be a firewall problem and BTSync uses a relay server.