btsyncfof

Awesome, that's exactly what I needed to know. Thanks!

I'm sorry if this question is totally irrelevant, but I figured it would be safest to check: Is BitTorrent Sync using OpenSSL, and if so, is it a version that is vulnerable to the Heartbleed bug? I have gone ahead and updated openssl on all of my linux machines, but I am curious to know if anything needs to be done for Windows machines w.r.t. BTSync specifically? Thanks!

I agree, I'd be interested in this service, but only if it took the Read-Only Encrypted secret. (which, to be fair, I can only generate because of the developer API key that I have)

Now that we've got Read-Only Encrypted secrets, any further ideas/updates on this? It would be a pretty compelling web service if it could accept a secret from you and just sync it and charge you per GB of storage, or something like that.

I just want to get a little bit of clarification on what "Restore modified files in read-only folder" means. Let's say I have two servers: server1 and server2. server1 has the folder /server1/sync, which is indexed by btsync. It gives server2 a read-only secret, and server2 syncs to /server2/sync. Lastly, let's say the sync folder contains a file test.txt. Now, does this mean, if /server2/sync/test.txt gets deleted, it will be regenerated from /server1/sync/test.txt? Thanks!

I'm currently allowing family members to backup to an always on server that I'm running. However, this means that I have a lot of read-only secrets to maintain, as my folder directory might look something like this: MyServer/Backups/ MeLaptop/ MeDesktop/ MePhone/ SiblingLaptop/ SiblingPhone/ ... you get the idea. Each of those subfolders has a read-only secret that needs to be applied. Now, I'm setting up a second server that should serve the exact same function as the first server - thus, the same file structure, the same keys, though the root path might be different, i.e.: MyServer2/Backups/ MeLaptop/ ... etc. Is there a relatively easy way to duplicate the setup with the keys? Or do I need to explicitly re-apply all of the keys to each folder? By "relatively easy", I suppose what I really mean is a sequence of steps that would remain constant in length regardless of how many subfolders there were. Thanks!

So it seems that currently, it's not possible to have two local folders correspond to the same shared secret. Why might I want to do that? Backups. I have an always on desktop with two external HDs attached. I would like a read-only copy of certain folders to be sync'd to both external HDs. MyLaptop/home <- (source) MyDesktop/MyHD1/ <- (backup) MyDesktop/MyHD2/ <- (second backup) However, if I point BTSync at MyHD1 and pass it a read-only secret, it will then prohibit me from adding MyHD2 with the same secret. I'm planning on purchasing a raspberry pi and setting it up as another always-on server, but I'm just wondering if it's on the roadmap to support a feature within BTSync that will make this setup possible, or whether this is considered out of scope for BTSync. Thanks!

+1. What will the solution for this look like? In particular, I'm looking to use BTSync as a way to take automated backups kind of like this: MyLaptop/home/ <- (source) MyBackupServer/MyLaptopBackup/ <- (backup - uses a read-only secret generated from source) However, there are some minor flaws with this. 1) Files can accidentally get deleted on the backup and they won't be re-sync'd. 2) Files on the backup are not encrypted so I can't use third-party servers for redundancy. In an ideal setup, I would like the backup to be an up-to-date mirror of the source, which means if a file were accidentally deleted on the backup but not in the source, it would be re-downloaded from the source. However, I don't want to have to get on the source node to issue a "force" command periodically, ideally, there would be a secret hash that would maintain those settings without requiring a manual "force" command. Additionally, since it's been said that it's on the roadmap for BTSync to support an encrypted read-only node, it would be ideal if there were a secret that would set a node with encryption and read-only mirror all at once. Is there any chance the feature will look like this, or are we going to be stuck issuing "force" commands? Thanks!