ChrisH

No, I still don't understand what you want and frankly I don't care anymore. File versions have nothing to do with this request.

Well, as someone already found out they started writing publicly accessible guides and manuals for 1.4, so some features at least seem to be fixed

30 GByte = 30720 MByte 2 Minutes = 120 seconds 30720/120 => 256 MByte per second average Unless you have a dedicated 10 GBit LAN, I seriously doubt that.

If you can rely on the salesmen not to change anything on the configuration side, fine. I would feel better if I had the control in my hands. I have a similar setup: Several internal BTSync servers, two public BTSync servers and lots of clients that should only connect to the public servers. The internal servers can only access the internet through the central firewall anyway, so it was not that hard to stop them from accepting any external BTSync connections. But if your setup works for you, by all means do it your way.

Can't you do it the other way round and set the internal Windows server to only sync with the external Linux server via the known host entry and disable all other options? Then the salesmen can set whatever they want in their local BTSync installation and still all they can connect to is the Linux box, because the Windows box won't connect anywhere else. Use additional firewall rules on the Windows server if needed. That way YOU will have control over the critical configuration settings, not your salesmen out in the world.

+1

Inspired by http://forum.bittorrent.com/topic/30920-active-distribuited-data-integrity-protection-raid-and-other-backup-obsolete/ but he explicitly stated there that this was not what he wanted: BTSync could periodically re-hash the files in the shared folders. If the current hash differs from the hash in the database, but the file change date is still the original, this indicates a corrupted file (i.e. a bit flipped somewhere in the storage subsystem). Files found corrupted should then be re-synced from any online peer, provided that their hash still matches the original. This should be a per-folder option. The re-hash interval can be configured and set quite high, like maybe once a month or so. Use case: Archived files that are almost exclusively read-only (photos, movies, MP3s, ISOs) but are kept on disk for months and years, thus having a bigger risk of bit rot. http://en.wikipedia.org/wiki/Data_rot

Then I give up. I like parts of what I thought you were suggesting (an active countermeasure against silent data corruption), but you just seem to want a cheap ZFS replacement for local files, which has pretty much nothing to do with what BTSync does. I therefore wouldn't hold high hopes for that request ever to make it into BTSync. You're wrong there. My aforementioned HP Microserver runs 8 GB of ECC RAM.

Okay, I'll stop discussing here. That's a killer phrase, not an argument. That's naive thinking. If I take over a host with your PHP script running on it, I have your sync secret and can just use that to play client instead of split peer.

Are we talking about remote changes that are synced via BTSync, or local changes? Because the former is already implemented and the latter IMHO is something for the OS or the filesystem.

Sorry, I still don't get it. How would BTSync know whether a change pushed by a peer is "malicious" or "authorized"? Regarding ZFS: No, it did not cost 2000$. http://www.freenas.org/ + a HP MicroServer for ~200 EUR.

Okay. So why do you think encrypting the data is not enough to protect against a malicious/compromised host? And why can't a compromised host simply use the secret that it already has (be it R/O or R/W or Encrypted R/O) to get the rest of the data from the other split peers?

Okay, that might work. Sorry, what? If the change was done intentionally by someone else I sync with, I want that change. I thought we were talking about bit rot. And I thought if file corruption was detected, the original should be recovered by resyncing that file, not by restoring an old version of the file from my own version archive (which also only works if the file was changed at least once since the first run). I already have ZFS and/or traditional backups for that.

Huh? It moves modified and deleted files at all peers (apart from the originating one) to a separate folder instead of "physically" deleting them and versions them with a number. If a configured age is reached, they are deleted. What's missing? I have to say I did not understand your last paragraph about uncooperative clients.

1. "Tricks" is not what comes to my mind if the topic is safety. 2. That's a completely new area (you named availability as the motivation in your first post). If you don't trust the host, don't use it or encrypt the data. If the encryption is broken or compromised (which means someone has your secret) it doesn't really matter if the data is stored all on one or distributed across many hosts. Also, what's keeping the compromised host(s) from using your parity block to recover the rest of the data, provided they can't just download it from the other hosts? Also, if the data is interesting enough, even leaking a part of a file (think videos, or word documents) might be enough to consider the attack successful. Sorry, I see neither the benefit of PHP over native hosting nor the attack vector your proposal tries to protect against. Could you elaborate?

When the file differs from the stored hash, how would BTSync know whether the file has changed intentionally or been corrupted?

BTSync already does that. Look into .SyncArchive.

A PHP version of BTSync seems a terrible idea to me. Also most Web hosters kill PHP scripts that are running more than a few seconds. Storage is cheap and will get even cheaper in the future - your "RAID" scheme seems a bit elaborate for me when I can just use one cheap Backupsy (or whatever) server as backup/distribution node and the original files on my PC.

You got it Also, you can't "decrypt" a hash, because it is a one-way function. You can just hash a lot of other data and hope one of them comes out as the same hash you try to "decrypt". http://en.wikipedia.org/wiki/Rainbow_table

Huh? You enter a secret into your client, the client hashes it and asks the network and/or the tracker server what IP(s) are linked to that hash. The algorithm to derive the hash from the secret is identical in every client. This is a one-way function, so you can't calculate the secret from the hash. You were talking about public and private keys, so I assumed you already knew how that works. If you run a tracker (which you can't as of now, btw) you know the hashes and the IPs, correct. You have to, otherwise tracking does not work. This has nothing to do with content.

Yes. Yes, but very very very very unlikely. No. That's essentially what it does: The BTSync tracker server has a list of hashes (the "public keys"). To connect to the server hosting the share and to decrypt the transmitted data you need the secret itself (the "private key").

Off-topic, since the question was already answered: Seriously? A "Please help" push post exactly ONE HOUR after you opened the thread? I wonder what reaction times you are used to and where I can get those

The way I understood it is that he wants to roll out BTSync to users without them having the secret. By your interpretation the requirement makes even less sense to me

Just give your mom a read-only secret and create a second folder (where she has r/w and you only have r/o) for the other direction, if needed.

+1