hiya daniel
On Wed, 21 Dec 2005, Daniel Webb wrote:
> That's exactly what I'm saying: your tar | gpg methodology has not accounted
> for the chance of a few flipped bits, because if it had, it wouldn't lead to
> massive data loss, which it does. Compressing/encrypting after archiving is
> inferior to compressing/encrypting before archiving when considering
> robustness. I just can't comprehend how you could dispute that.
i been doing "tar" for 25+ years... so i trust it ... and yeah
each bversion of tar or any other apps has the same vulnerability
you are inferring, including your own *pio apps
tar is no better at checking for flipped bits, not better/wrost than any
other application can figure it out
- it is in fact impossible for an app to know a bit
is flipped or not, unless itknew ahead of time what it is
supposed to have been
- whether its corrected on the disk platter, in the disk buffer
or in memory is a separate issue
"applications" has zero business changing my 1001 to 1000
- if you use md5 or anything other method to generate a unique
pattern, what guarantees that the md5 itself is not corrupted
- this is an endless argument of "correcting what you think is an error"
on the fly without user intervention is impossible
- fixing disk errors on the fly... burst mode ecc, single bit ecc, etc
is a spearate issue and is designed specifically for that purpose
and has ZERO capability of the userland sw to change it other than
to rewrite the original data and the new ecc databits
> code changes than tar in the last 5 years. I'm guessing you don't know
> anything about it based on your comments.
this comment has degraded your possibly intelligent arguments into
useless /dev/null as you implied you do not "understand" who or what
you're talking about by making false/dumb accusations about your debator
that happens to differ with your choices and reasons
> I still don't see anything in that list that tar has but afio doesn't.
good ... that's my whole point ...
> I *do*
> know one thing that afio has that tar doesn't: much greater robustness in the
> case of corruption.
"robustness" against corruption can be accomplished and guaranteed
at least a dozen different ways ... possibly hundred different ways
> Whether you "trust" your hardware or not,
that is one issue that has nothing to do with anything else
> it doesn't make
> sense to me to choose a less robust solution over a more robust solution.
"robustness" for you may be a micky mouse solution to others
and vice versa.....
let the decision makers and customers decide what is important to you
and they can learn it or trust somebody's "opinion" over another
- you do it your way .. you are right .. in what you're doing
- i'll do it my way ... for what i need done ... out of what
is proposed, budgeted, required, etc, etc...
c ya
alvin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
