Fair enough, but I think it’s important to make users aware of the actual purpose and downsides of -bit-identical
, and point them to the more relevant docs (the -copy
option) so they can read up on it…
One of the recurrent issues with Duplicacy design, is that invariably, new users come a cropper when wanting to add copy-compatibility to their existing setup and discovering they should’ve used add -copy
instead of another init
on the second storage.
Likewise, once you create a copy-compatible storage with -bit-identical
, you can’t really undo that choice. IMO, it’s exactly the same problem as password re-use - nobody can truly predict how it will impact security, but it has the real chance to bite you in the ass. Already, I can imagine various ways a dedicated hacker would abuse that choice, despite otherwise good security practices.
Ideally, it would be nice if one day Duplicacy could copy between any storage without prior preparation. I believe it’d be technically feasible to do, if a little complicated. Even with different chunk sizes, variable or fixed.
Anyway, I don’t particular think -bit-identical
and third-party copying adds that much convenience anyway, and it may introduce problems of its own. An added advantage of letting Duplicacy do the copying - in addition to being able to specify a subset of snapshots - is that it actively decrypts and re-encrypts chunks. This effectively validates the integrity of data, as it would assuredly error out when encountering corruption.