summaryrefslogtreecommitdiffstats
path: root/sys
diff options
context:
space:
mode:
authornate <nate@FreeBSD.org>1995-08-16 23:12:25 +0000
committernate <nate@FreeBSD.org>1995-08-16 23:12:25 +0000
commitde358b51395dcaf18a7105b50845833bda2c3c69 (patch)
tree00f6f8d8d30873cb93e83eaffc76ab01935064e4 /sys
parent39e93879b80ed307b1741bc9123f402800c8e954 (diff)
downloadFreeBSD-src-de358b51395dcaf18a7105b50845833bda2c3c69.zip
FreeBSD-src-de358b51395dcaf18a7105b50845833bda2c3c69.tar.gz
Fix possible FS corruption caused by extra parameter to pax.
oo Turns out, it's pretty important if you use PAX for backup. In the man page for PAX, there is an error (OK, we could call it a "potentially catastrophic incompleteness"). It reads: > The command: > > pax -r -v -f filename > > gives the verbose table of contents for an archive stored in filename. Yup, it does do that. With a side effect: it also _replaces_ all the files that come in from the archive. As is my custom, I did my backup-validation real soon after the backup was written. Precisely because I've seen the same sort of thing happen on other systems. So all that file-restoring didn't do a lot of damage. Probably helped my fragmentation somewhat (aha, an online defragger?) It did confuse one hapless user, who lost an email message he _knew_ he hadn't deleted. Apparently the system restored the file as of just before that critical message came in. The correct entry should read: > The command: > > pax -v -f filename > > gives the verbose table of contents for an archive stored in filename. Submitted by: John Beckett <jbeckett@southern.edu> via the BSDI mailing list
Diffstat (limited to 'sys')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud