'too old', use pathconfat(_PC_TIMESTAMP_RESOLUTION, AT_SYMLINK_NOFOLLOW)
to get the timestamp resolution to which the _source_ timestamp
should be truncated for a stable comparison.
Problem reported by Walter Alejandro Iglesias (wai(at)roquesor.com)
ok millert@
This fixes a problem where the file list output was fully-buffered
when used as part of a pipeline. With this change, files are listed
as they are extracted in verbose mode. OK deraadt@ guenther@
The existing tar_opt() implements support for -o write_opt=nodir for the
old tar and ustar formats. We don't really want to support it for the
pax format, and we want to be able to implement pax format specific
options (even if there are none right now). ok millert@
Lets us store longer file names, link names, finer grained timestamps,
larger archive member files, etc; at the expense of larger uncompressed
archives and less widespread support across the ecosystem. If you're
unhappy with the new defaults, you can use -F ustar. Or you can help
fix bugs / find a better middle ground.
Prodding from various including job@ and deraadt@
ok sthen@ caspar@ millert@
512 bytes isn't enough if you want to store rather large but still
useful long file names or symbolic links destinations. The best way to
size the buffer to read those records is based upon the largest paths
pax(1) can handle, and that is PAXPATHLEN.
Reported by caspar@, input and ok millert@
We want to move towards 'pax' as the default format for writing, this
option lets users downgrade to -F ustar where the 'pax' format isn't
convenient/usable (same as -x <format> in pax(1)).
-F <format> is more generic than -o/-O. -H (GNU tar) was already used
and we don't want long options so --format (NetBSD/FreeBSD) is excluded
too.
ok sthen@ caspar@ millert@
We expect that existing pax archives start with a global or extended
header. If they don't, append operations will be done using ustar
format.
Fixes append mode on pax archives where pax(1) would bail out when
appending to pax archives, falsely detecting a mismatch. Reading was
unaffected. Reported by caspar@, ok caspar@ millert@
Access time can't be represented by ustar, so always include it when
using the pax format. Also include an extended header record for mtime
if the file modification time can't be fully represented by ustar (eg
subsecond resolution).
Input & ok millert@
Keep writing archives in ustar format by default. People can test the
posix 'pax' format using pax(1) -w -x pax ... or cpio -o -H pax ...;
tar(1) can't exercise this code yet. Only long names file and link
names are supported for now.
With input and tests from caspar@, ok millert@
Spotted while comparing ktraces between 'tar -z' and 'gzcat | tar -f-'.
Only the former runs, e.g. gzip(1), but the latter also pledges theses promises
just to pledge again immediately afterwards without them.
Make the calls mutually exclusive so 'tar -f-' et al. skip the first pledge
and thus never have "proc exec" to begin wth.
"looks good to me" mbuhl
OK millert
-DSMALL has never been used to build the ramdisks, thus the support for
reading pax format archives has always been there. This is misleading,
so just zap the ifdef since we want to keep read support.
Went through a make release Just In Case(tm).
Spotted by caspar@, ok millert@ sthen@ caspar@
Previously, when creating an archive file with pax(1), pax will attempt
to open a file even if the file will be skipped due to an -s replacement
with the empty string. With this change, pax will not attempt to open
files that it knows will be skipped.
When doing direct copies to a directory (-rw), pax already skips
the file before attempting to open it. So this makes the behavior
more consistent.
This can measurably speed up pax when skipping a large number of files.
OK tb@
initializers as they are not required to be compile-time constants.
So, intialize these global variables at the top of main().
ok miod@ deraadt@ yasuoka@ millert@
getopt(3) returns '?' when it encounters a flag not present in the in
the optstring or if a flag is missing its option argument. We can
handle this case with the "default" failure case with no loss of
legibility. Hence, remove all the redundant "case '?':" lines.
Prompted by dlg@. With help from dlg@ and millert@.
Link: https://marc.info/?l=openbsd-tech&m=167011979726449&w=2
ok naddy@ millert@ dlg@
These are becoming quite common in distributed software (including
tars produced by Python and Go) and often standard timestamps are
not set, resulting in extracted files dated as the epoch.
Lots of help from tb@, ok tb@ millert@
3rd (variadic) mode_t parameter is irrelevant. Many developers in the past
have passed mode_t (0, 044, 0644, or such), which might lead future people
to copy this broken idiom, and perhaps even believe this parameter has some
meaning or implication or application. Delete them all.
This comes out of a conversation where tb@ noticed that a strange (but
intentional) pledge behaviour is to always knock-out high-bits from
mode_t on a number of system calls as a safety factor, and his bewilderment
that this appeared to be happening against valid modes (at least visually),
but no sorry, they are all irrelevant junk. They could all be 0xdeafbeef.
ok millert
value < 0. errno is only updated in this case. Change all (most?)
callers of syscalls to follow this better, and let's see if this strictness
helps us in the future.
