| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are too long. Filenames escaping this test are caught later on,
so the bug doesn't cause any breakage.
Document the correct ustar limitations in pax. As I have no access
to the IEEE 1003.2 spec, I can only assume that the limitations
imposed are in fact correct.
Add regression tests for the filename limitations imposed by pax.
MFC after: 3 weeks
|
| |
|
|
|
|
|
|
|
|
|
| |
wording makes it look like pax archives > 32256 bytes are not
POSIX-compliant! Correct this to state that pax archives with
block sizes > 32256 are not POSIX compliant...and settle our fears.
PR: docs/97059
Reviewed by: Giorgos Keramidas <keramida>
|
|
|
|
| |
Sort standard sections in the (documented) preferred order.
|
| |
|
|
|
|
| |
by POSIX.
|
| |
|
| |
|
|
|
|
| |
OK'ed by: imp, core
|
| |
|
| |
|
| |
|
|
|
|
| |
Reviewed by: brian
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are:
* Implement cpio compatibility mode when pax is invoked as cpio
* Extend tar compatibility mode to cover many of the GNU tar single-letter
options (bzip2 mode, aka -y/-j is not present in OpenBSD). When
invoked as tar, pax is now full-featured enough for use by the ports
collection to extract distfiles and create packages.
* Many bug fixes to the operation of pax and the tar compatibility modes
* Code fixes for things like correct string buffer termination.
I tried to preserve existing FreeBSD fixes to this utility; please let me
know if I have inadvertently spammed something.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and compress) to pax when used in tar mode (invoked as 'tar') for
compatibility with GNU tar.
bzip2 functionality for further GNU tar compatibility will be added at a
later date.
Note in the manpage that -z is non-standard.
Obtained from: OpenBSD
Reviewed by: -hackers
MFC after: 2 weeks
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
of the typeset output, tend to make diffs harder to read and provide
bad examples for new-comers to mdoc.
|
| |
|
|
|
|
| |
Submitted by: Philippe Charnier <charnier@xp11.frmug.org>
|
|
|
|
|
| |
PR: 6801
Reviewed by: David Kelly <dkelly@hiwaay.net>
|
| |
|
|
|
|
| |
Use .An/.Aq
|
| |
|
|
|
|
|
|
|
|
| |
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|