symlinks after setting the owner. As a result, mode
and timestamp were not restored. This patch corrects the
problem by simply removing the short-circuit for symlinks
and using lchown()/lchmod()/lutimes() always for restoring
metadata.
PR: bin/91316
Submitted by: Jaakko Heinonen
Reviewed by: Joerg Sonnenberger
MFC after: 14 days
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>
WRT handling file and link names that reach the allowed
maximum for old tar and ustar archive formats.
PR: bin/40466
Submitted by: Cyrille Lefevre <email in the PR> (portions)
Reviewed by: freebsd-arch (silence)
MFC after: 1 month
rev 1.18, but not documented in the man page) caused a failed chdir.
Otherwise, one can easily overwrite files.
Submitted by: Robert Nagy <robert@openbsd.org>
Obtained from: OpenBSD
that this provokes. "Wherever possible" means "In the kernel OR NOT
C++" (implying C).
There are places where (void *) pointers are not valid, such as for
function pointers, but in the special case of (void *)0, agreement
settles on it being OK.
Most of the fixes were NULL where an integer zero was needed; many
of the fixes were NULL where ascii <nul> ('\0') was needed, and a
few were just "other".
Tested on: i386 sparc64
Instead use %ju and cast the argument.
WFORMAT=0 is still required in the Makefile because gcc warns about
some strftime() calls (I don't think this behaviour is useful.)
Tested on: sparc64, alpha, i386
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
characters. Use quad conversion functions rather then long conversion
where appropriate to handle the available range. Mainly fixes time_t
but there was also a st_size ulong conversion in there that has to be
quad or cpio cannot be used to copy files > 2G.
MFC after: 1 day
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
: LC_TIME This variable shall determine the format and
: contents of date and time strings when the -v
: option is specified.
Developers took this wrong. LC_TIME specifies the locale
name, not the ``format'' argument of strftime().
Oops:
pax -w -f /tmp/foo /dev/null
LC_TIME=de_DE.ISO_8859-1 pax -v -f /tmp/foo
pattern matches will occur at offset zero of the source string. The bug causes
the input source string pointer to be incremented by the offset of the end of
the match, instead of it's length. The fix is to only increment the pointer by
the length of the pattern match (eo-so).
Of course, the one example in the man page shows a situation where the match
occurs at offset 0.
Submitted by: John W. DeBoskey <jwd@unx.sas.com>
Obtained from: freebsd-current@freebsd.org
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
