6 Commits

Author SHA1 Message Date
Martin Matuska
2ad1419f1b Update bsdtar to 2.8.4
Use common code from lib/libarchive/libarchive_fe

Approved by:	kientzle
MFC after:	2 weeks
2011-07-17 21:33:15 +00:00
Tim Kientzle
c7e120041d Merge from libarchive.googlecode.com: Numerous Windows-specific build tweaks. 2009-04-17 03:36:07 +00:00
Tim Kientzle
74d5acaf4c Merger r629-631,633-646,648,654,678,681,682 from libarchive.googlecode.com:
Many changes for Windows compatibility.  bsdtar_test now runs successfully
on both POSIX platforms and Windows.
2009-03-08 05:47:21 +00:00
Tim Kientzle
e8f0b45249 Merge r374 from libarchive.googlecode.com: Stupid typo in open() call. <sigh> 2009-03-08 05:19:36 +00:00
Tim Kientzle
8666079cdb Include more detailed explanation of this case, since it's pretty
subtle why it comes out the way it does.  Once you realize that it
depends on the archiving order, it's also important to realize that
filesystem differences aren't going to break this case.  (Some of the
other tests have had to be extensively rewritten to make them
independent of the order in which a particular filesystem returns file
entries.)

(This commit also serves to note the PR number that I accidentally
omitted from the previous commit.)

PR:		bin/128562
MFC after:	30 days
2008-11-10 05:24:13 +00:00
Tim Kientzle
c4a52c7226 Test --strip-components and fix it to actually work. Jaakko did a
good job writing this test; it exercises a lot of subtle cases.  The
trickiest one is that a hardlink to something that didn't get
extracted should not itself be extracted.  In some sense, this is not
the desired behavior (we'd rather restore the file), but it's the best
you can do in a single-pass restore of a tar archive.

The test here should be extended to exercise cpio and newc formats as
well, since their hardlink models are different, which will lead to
different handling of some of these edge cases.

Submitted by:	Jaakko Heinonen
MFC after:	30 days
2008-11-10 05:04:55 +00:00