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

bin/pax/pax.1

@@ -34,7 +34,7 @@
 .\" SUCH DAMAGE.
 .\"
 .\"	@(#)pax.1	8.4 (Berkeley) 4/18/94
-.\"	$Id$
+.\"	$Id: pax.1,v 1.2 1994/09/24 02:56:26 davidg Exp $
 .\"
 .Dd April 18, 1994
 .Dt PAX 1
@@ -1048,7 +1048,7 @@ copies the contents of the current directory to the device
 .Pa /dev/rst0 .
 .Pp
 The command:
-.Dl pax -r -v -f filename
+.Dl pax -v -f filename
 gives the verbose table of contents for an archive stored in
 .Pa filename .
 .Pp