AcostaJA

As most routers does offer NAS features, it's a natural step to enable btSync on it. Most common way is to build optware packages compatible with asus native os and Openwrt as well compatible with ddwrt, but also ddwrt developers use to pre install some packages on ddwrt (as transmission) btSync would be an popular add on in routers loaded with open-source os.

I whish btSync to have a file block hash database, so when a block of data it's required by file being sync the peer first check it hash against the database If found it already present on a particular local file then just take it from such local file. This feature allows for an optimal bandwidth utilization since some files may share exactly the same partial or total data, it's an very common scenario to take on count and thus avoid to tx/rx data already on local files. Such block hash database also could be important for other features I previously requested as key element on data integrity protection.

I don't want to start a battle here, it's good to read moderator are not absent.

Updated this part on the Original post, Improving readbility and correcting typos to first part, and to general improve the second part of the request. Given on p2p environment Parity Data is required to be complete on each peer, has no sense to split th parity file among peers, while an useful resourse to have such parity on each peer.

*Updated the first post to expand further details on the request, which provides a sor of CVS on team enviroments.

[this post has been removed]

Good to see you finally understand my feature request, do not need to duplicate. Now you realize what is data integrity protection (bit rot is just an scenery). Now you understand too why it's so important to keep file versions all along.

That's relative, you think on deploy the same btSync on the splitted peers, I think on an specific btSync for splitted peers with the capability to send parts to other splitted peers disabled totally even w/o dht info which allows it to find nothing than other std peers. Naive thinking is what I name when someone don't provide ideas instead critique recursively with weak reasoning or acting like dumb, sorry actually this is not naive thinking, this is trolling. Thanks for your time, my hope is that the idea behind this feature request will be well understood by btSync team.

That micro server still needs 4 hdd (add =600$ for 4x3tb ) + ecc ram thus reaching =1100, not to mention the cpu not powerful enough for a decent nas4free implementation with encrypted storage or adequate for remote ssl access. Thanks for your time, however I don't want your share my focus, I'm only providing an idea here, if you judge it as *a cheap zfs it's* OK, I name it *something some people will find useful*.

1- when safety matters, never is enough. 2- split peers are passive with respect other splitted peers, don't know their ip address, location etc, to rebuild a file are required n-1 parts plus the parity, splitted peers only have one single part and the parity

This Is not matter of this feature request. A zfs optimal implementation requires an box capable to host ECC RAM, plus at least 4 hdd for raid z2 (minimum raid level recommend) also at least 1 gb of ECC ram per TB of available disk space upto 5gb of ECC RAM per TB if you want to use de duplication feature. The cheapest hardware with this characteristics cost 1200$ (core i3 on c602 mb) add this 16gb ECC ram (200$+-) and 4 storage class hdd (wd red or hgst enterprise) this add near 600 $ (4x2 tb). A non optimal deployment of zfs means an sub espec service.

Trick it's just a word, while the method used deliver stable operation it's plausible to deploy to production. *from now I'll name Web based peers (hosts) as splitted peers, and non-splitted peers as std peers (conventional btSync peers) . * 1 as rule the host will only receive the partial data assigned, plus the parity, no host rebuilds data, only the std peers are capable to *assembly* the file, no splitted peer must be aware where are the other splitted peers, only contact the std peers, only std peers are aware the splitted peers location. 2 since It's required N-1 Blocks plus the parity block to rebuild the data, no peer will have N-1 blocks, only 1 block plus the parity block, if your clould comprises 3 splitted peers and a single host is seized or comprised, this host requires at least to download an extra block for another splitted peer, this thing will not happen since the rest of the splitted peers only can deliver its content to an std peer. 3. Compromising the network security is not a problem addressed by this feature, only the availability and security of stored data at SAN level on an remote host.

Some OS(or installs) just don't provide a system even triggered when some file system object it's modified, those are what I name uncooperative clients. I'll review on detail the feature, from as long I've read it's limited to something like a trash can function.

Chris you miss the point, an authorized modification on a shared file is not what this feature wants, but an malicious one, or at least warn the owner about that modification and provide a safe path for recovery if wanted, this why must be offered with the other feature proposed (file snapshot version protection). Congrats for your ZFS storage until Btrfs is released its the best on data protection, sadly common people can't afford a NAS adequate for ZFS (I assume you use raid z2) it cost 2K$ and up I'd implemented by professionals, plus the mess to supervise the server, btw it's the best today, my suggestion tries to provide a bit if that to common people that only has a laptop, a tablet an smartphone and few fortunate a cheap 300$ NAS. [emoji3][emoji2][emoji1]

1. PHP scripts running in background are possible to keep alive thru N ways (name it tricks). 2. Is not about storage cost, but safety, if I put only a partial content of an encrypted file, it's impossible to rebuild it if the security is comprised (logically no file stored in a cloud serve maybe sent plain).