lolcat

That seems unfortunate. I hope they reduce the multicast traffic and the issue with small files.

Sure it could be done. But it would require far less to implement nested shares. With nested shares this becomes far easier. If you move the files out of the folder, and create hardlinks to the btsync folder I guess it would work, but it would still be a sub-par solution.

Why would you use BTSync for backups? They actually make backup software that has had their encryption reviewed and is supplied by trusted companies. I agree the prices is crazy for many of these services, and I do wish that I could extract the torrent files and add them to a normal seedbox (they have far better prices). If you were to only transfer a few documents I would rather have a couple of friends seed it for me. Or leave the files on my fileserver. But in that usecase I don't see why anyone would use BTSync and not sftp or rsync. If not for the P2P part, what is the point? The lack of good version conflict resolving makes it useless for collaboration. The only usecase I can see is if you need to share a large folder with several other people.

The biggest obstacle is the lack of nested shares. P2P yields no advantadge if you can't actually do P2P. As it is now you could end up in a situation where you need one share per file, and that is obviously difficult to acheive effectivly. If I could make virtual shares I would be able to share with the users what they need, and they would provide bandwidth.

Can BitTorrent Sync have one server and many read only users? Yes, you can have as many read-only users as you would like. Whether the data from the read only user to another read only user transmitted correctly (same as on server)? I have no idea what you are asking. But with multiple read-only nodes the files will be transmitted between them and from the server. So if the server goes down you can still get updates from other peers. Why the server loading data from users read-only? Is it?

How do you suggest you "bond" two sepparate internet connections? Any Bittorrent client with respect for itself can bind to multiple interfaces. Me for instance, I have two internet connections, my ISP would never let me "bond" them, but I could still use both for BTSync to increase speeds. To use two shares would be an option if the share is small, for terrbyte sized shares not as much.

By folders do you mean shares? It is confusing when we don't use the same terminology. Share: A sync folder Folder: An actual folder, a share can contain many folders

Why on earth would it do this? Unless you are seeding there is no point in reindexing the files.

But for uptime BTSync would be terrible. And you certanly won't get ZERO downtime. Raid can protect you against hardware failure, with ZERO downtime as he asks for. ZFS for instance can be sent to another server too, for an offline backup identical to the first. If all drives dies, just plug in one from the backup location. Raid is a far better solution.

http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-of-open-files/ Tried this?

Wouldn't a raid be infitintivly more usefull for this purpose?

If I share a folder with you and my mother, then you will upload to my mother, and my mother will upload to you. If I create to separate shares, and share one with you and one with my mother, I will have to upload it to both, and be online until both finishes. In the first scenario using BTSync makes sense, in the second it is a waste of cpu-cycles as a webserver or sftp server would do the same job with far less overhead. Having the downloaders seed to eachother is paramount for this software to have any purpose. cpu-cycles and I/O Is abundant in home systems, but upload bandwidth isn't.

But then you can't cross seed, so you lose the advantadges of P2P.

Doesn't the sqlite database keep track of this?

Known issues1.BitTorrent Sync may handle events incorrectly in the following cases:•.!sync files are changed outside of BitTorrent Sync•no free disk space left Took me a while to find it. I just love PDFs, I wish they could use a bigger font and upload it in PNG; would make searching and reading more fun. Does this apply for read-only nodes and encrypted-only nodes? If so isn't it a pretty big security problem?

The interessting difference between BTSync and a normal torrent is that it has to encrypt the file (or parts of it) before seeding, I assume this can create some odd behavior. For a normal torrent you can access all the files you want to seed at random, but BTSync can't do that, because the files it is seeding doesn't exist on the drive. The way it gets around this is by caching pieces of the files in a database, and then I assume (and hope) it prioritizes seeding those pieces before it encrypts another file and seeds that.

4MB chunks? As far as I can tell the pieces (proper bittorrent lingo) are dynamically sized, it makes no sense to use 4MB pieces for 1MB files. Ofcourse read-only nodes seed to other nodes, if not the whole point of the software would be gone. How they prevent read-only nodes from tampering with the share is yet to be explored.

If it runs as a service the server would have to be on, but you don't need to be "logged in". If you turn of the server obviously it can't seed. Not sure what you mean with a "logged off server", my servers never turn off and I log in when I need to monitor or configure them.

Is there any firewalls between them?

"tar -xvzf" without the quotes usually unpacks .tar.gz for me.

Remember the encryption used by BTSync has not been independently reviewed, the data can still be captured by an adversary in transit, and Bittorrent inc is a US company, so they can be forced to implement backdoors and they would not be allowed to tell the users about it. It is NOT suited for confidential information. I would not transfer a password database using it without having it independently encrypted (but then you would be just as well off using DropBox). Why the media belives it is "NSA safe" is a mystery to me, there is ample evidence they can just store what is sent over the internet, and encryption that isn't documented or independently reviewed is worthless. Closed source software from the US can also not be trusted, service providers has (and can) be forced to implement a backdoor.

Selctive sync is a pretty important feature for a lot of us. I have netbooks with 20GB of storage, I can't sync what my normal computers have to it, but I would still want to be able to use the speeds my swarm provides to download files on request. Setting up transparently encrypted torrents, using SSL Torrent (feature of libTorrent) would essentially replace all the features of BTSync and add tons of features (virtual shares, and so on).

I want to use my toaster under water in my bath tub, that doesn't make it a good idea. BTSync would be usefull to replicate a backup made by proper backup software, the software should have version control, the ability to check the integrity of the backup, and for compatibility with BTSync it should not change existing files as the version control is mediocre. I would use a combination of for instance CrashPlan and BTSync, then you can create a backup to an external drive, and then seed it to ten people and then the backup uploading would be far smaller after the initial backup. Or you could send a drive with the backup to the person who has the most bandwidth and less him/her seed it. A backup program that uses the P2P abilities of bittorrent and has the ability to share backups easily would be brilliant. CrashPlan lets you back up to friends, but you have to upload the backup once to each computer. This is obviously a terrible solution if you have limited upload bandwidth or a huge dataset to back up. Also being able to use several providers without wasting ram and bandwidth.

The point is using BTSync for replication of folders on one computer would waste resources. It uses more CPU cycles, more ram, and more I/O than rsync would. It is like asking how you best can use scissors to mow your lawn, any sane person would tell you scissors would not be the right tool for the job, and would waste time and give you a sub-par result. I don't use Windows, but I am sure it has some sort of software to synchronize two folders that would have far less overhead than BTSync. The bitorrent protocoll is good for distributing files among many nodes, this is where it has advantadges. It allowes one person to share a file, or a set of files with an unlimited number of people, and in the best case scenario it won't cost more than the bandwidht to upload it once. To replicate files locally however it would just waste resources, if you share has encryption you have to encrypt each file, add it to a database, send the piece, decrypt the piece and then write to the drive. This is so incredibly wastefull. Ofcourse you can argue BTSync should do everything, but that would be pointless, you need simple efficient tools that does the job they are designed. The complexity wouldn't matter, all you would have to do is to use the built in copy command of the OS, hardly a complex operation. It would probably require less disk I/O, ram and cpu cycles to just delete the old folder and then copy the new folder.

Can't you just make two shares? And then copy files when you do something with them? You give him a read-only secret, he gives you a read-only secret. Then you can share whatever, and changes made at the other end won't be sent back.