* Implement --use-compress-program using new libarchive feature.
* Minor portability improvement by adjusting casts used to
print out uids, gids, and device numbers.
Thanks to: Joerg Sonnenberger for the --use-compress-program implementation.
MFC after: 15 days
failed path is one which was specified on the command line.
This is a compromise between the situation prior to revision 1.57
(where a race between tar(1) and rm(1) could cause tar(1) to
spuriously report an error) and the situation after revision 1.57
(where "tar -c /no/such/path" prints a warning but returns with
an exit code of zero).
Inspired by: rafan
MFC after: 1 week
occur on the write side of extracting a file to ARCHIVE_WARN errors
when returning them from archive_read_extract.
In bsdtar: Use the return code from archive_read_data_into_fd and
archive_read_extract to determine whether we should continue trying to
extract an archive after one of the entries fails.
This commit makes extracting a truncated tarball complain once about
the archive being truncated, instead of complaining twice (once when
trying to extract an entry, and once when trying to seek to the next
entry).
Discussed with: kientzle
into separate append_archive and append_archive_filename functions; the first
takes a "struct archive *" as input, while the second takes a filename, opens
the archive, and calls the first.
There should be no changes in behaviour as a result of this commit; it simply
reorganizes code to make more sense. At some point in the future it may be
possible to share code between append_archive and read_archive, but not yet.
Discussed with: kientzle
affecting the return value from bsdtar), since (a) it usually occurs
due to a perfectly innocent (and unavoidable) race condition where a
user deletes a file in the window between bsdtar reading a directory
and attempting to read the file; and (b) aside from printing a warning
message, bsdtar behaves exactly as if the file had been deleted prior
to bsdtar reading its parent directory.
Reviewed by: kientzle
MFC after: 6 days
complaining about lstat(2) failing. It's a bit scary to find the message
tar: /: Cannot stat: No such file or directory
printed while doing a backup.
MFC after: 1 week
better job searching for the bsdtar binary to test and the gtar binary
to use for inter-operability testing. It should now find the built
(but not installed) binary if there is one, then search for an
installed binary in a number of standard locations.
* New test scripts exercise some basic functionality
* Most header inclusions are now protected (portability)
* read.c now relies on security checks in libarchive instead
of trying to do its own (optimization)
* -p now enabled by default for root, add --no-same-permissions
to disable it
* Comments, minor style fixes.
as part of an old configuration shuffle. As a result, although
ACL restore has been working, ACLs haven't been written into archives
for some time. <sigh>
Pointy hat: You know.
MFC after: 3 days
determine if this is a physical dir without an lstat().
While I'm in here, try to clarify the comments around
the _is_dir() and _is_physical_dir() tests.
(as determined by the initial size given to the header).
Libarchive recently changed to correctly return the amount
of data actually consumed in this case, which revealed this
bug in bsdtar.
* Create file if it doesn't exist.
* If archive is "empty", then append to it with pax restricted
* If user specified a format, use that if it's compatible with
the existing format.
forthcoming. This commit also has a number of style(9) fixes and
minor corrections so the code works better with the build system being
used for non-FreeBSD builds.
Many thanks to: Jaakko Heinonen, who proposed a mechanism for extended
attribute support and implemented both the machine-independent portion
and the Linux-specific portion.
(I'm not using GPL, but I still think there are good
ideas in the GNU projects. ;-) Among other things,
this should make it easier for clients of bsdtar to
recognize it automatically:
bsdtar --version | grep bsdtar
chdir(), be sure to undo the effects of the chdir before continuing.
Without this, after hitting a directory with mode 0111 (for example),
tar will get lost, and won't add any yet unvisted files to your
archive. (Or possibly add the wrong files, I suppose...)
Reviewed By: kientzle@
option is undocumented because it does nothing. It does nothing
because bsdtar never needs it. It is accepted because gnutar does
sometimes need it and many scripts use it.
Reported by: Pawel Jakub Dawidek
