d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
01a94543e9
freebsd-dev/lib/libarchive/test/test_write_disk_hardlink.c

242 lines
8.6 KiB
C
Raw Normal View History

Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
/*-
* Copyright (c) 2003-2007 Tim Kientzle
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include "test.h"
__FBSDID("$FreeBSD$");
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
#if defined(_WIN32) && !defined(__CYGWIN__)
/* Execution bits, Group members bits and others bits do not work. */
#define UMASK 0177
#define E_MASK (~0177)
#else
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
#define UMASK 022
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
#define E_MASK (~0)
#endif
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
/*
* Exercise hardlink recreation.
MFp4: libarchive 2.5.4b. (Still 'b' until I get a bit more feedback, but the 2.5 branch is shaping up nicely.) In addition to many small bug fixes and code improvements: * Another iteration of versioning; I think I've got it right now. * Portability: A lot of progress on Windows support (though I'm not committing all of the Windows support files to FreeBSD CVS) * Explicit tracking of MBS, WCS, and UTF-8 versions of strings in archive_entry; the archive_entry routines now correctly return NULL only when something is unset, setting NULL properly clears string values. Most charset conversions have been pushed down to archive_string. * Better handling of charset conversion failure when writing or reading UTF-8 headers in pax archives * archive_entry_linkify() provides multiple strategies for hardlink matching to suit different format expectations * More accurate bzip2 format detection * Joerg Sonnenberger's extensive improvements to mtree support * Rough support for self-extracting ZIP archives. Not an ideal approach, but it works for the archives I've tried. * New "sparsify" option in archive_write_disk converts blocks of nulls into seeks. * Better default behavior for the test harness; it now reports all failures by default instead of coredumping at the first one.
2008-05-26 17:00:24 +00:00
*
* File permissions are chosen so that the authoritive entry
* has the correct permission and the non-authoritive versions
* are just writeable files.
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
*/
DEFINE_TEST(test_write_disk_hardlink)
{
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
#if ARCHIVE_VERSION_NUMBER < 1009000
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
skipping("archive_write_disk_hardlink tests");
#else
static const char data[]="abcdefghijklmnopqrstuvwxyz";
struct archive *ad;
struct archive_entry *ae;
struct stat st, st2;
/* Force the umask to something predictable. */
umask(UMASK);
/* Write entries to disk. */
assert((ad = archive_write_disk_new()) != NULL);
/*
* First, use a tar-like approach; a regular file, then
* a separate "hardlink" entry.
*/
/* Regular file. */
assert((ae = archive_entry_new()) != NULL);
archive_entry_copy_pathname(ae, "link1a");
archive_entry_set_mode(ae, S_IFREG | 0755);
archive_entry_set_size(ae, sizeof(data));
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assertEqualInt(sizeof(data),
archive_write_data(ad, data, sizeof(data)));
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
/* Link. Size of zero means this doesn't carry data. */
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assert((ae = archive_entry_new()) != NULL);
archive_entry_copy_pathname(ae, "link1b");
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_set_mode(ae, S_IFREG | 0642);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
archive_entry_set_size(ae, 0);
archive_entry_copy_hardlink(ae, "link1a");
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assertEqualInt(ARCHIVE_WARN,
archive_write_data(ad, data, sizeof(data)));
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/*
* Repeat tar approach test, but use unset to mark the
* hardlink as having no data.
*/
/* Regular file. */
assert((ae = archive_entry_new()) != NULL);
archive_entry_copy_pathname(ae, "link2a");
archive_entry_set_mode(ae, S_IFREG | 0755);
archive_entry_set_size(ae, sizeof(data));
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
assertEqualInt(sizeof(data),
archive_write_data(ad, data, sizeof(data)));
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/* Link. Unset size means this doesn't carry data. */
assert((ae = archive_entry_new()) != NULL);
archive_entry_copy_pathname(ae, "link2b");
archive_entry_set_mode(ae, S_IFREG | 0642);
archive_entry_unset_size(ae);
archive_entry_copy_hardlink(ae, "link2a");
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
assertEqualInt(ARCHIVE_WARN,
archive_write_data(ad, data, sizeof(data)));
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/*
* Second, try an old-cpio-like approach; a regular file, then
* another identical one (which has been marked hardlink).
*/
/* Regular file. */
assert((ae = archive_entry_new()) != NULL);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_pathname(ae, "link3a");
MFp4: libarchive 2.5.4b. (Still 'b' until I get a bit more feedback, but the 2.5 branch is shaping up nicely.) In addition to many small bug fixes and code improvements: * Another iteration of versioning; I think I've got it right now. * Portability: A lot of progress on Windows support (though I'm not committing all of the Windows support files to FreeBSD CVS) * Explicit tracking of MBS, WCS, and UTF-8 versions of strings in archive_entry; the archive_entry routines now correctly return NULL only when something is unset, setting NULL properly clears string values. Most charset conversions have been pushed down to archive_string. * Better handling of charset conversion failure when writing or reading UTF-8 headers in pax archives * archive_entry_linkify() provides multiple strategies for hardlink matching to suit different format expectations * More accurate bzip2 format detection * Joerg Sonnenberger's extensive improvements to mtree support * Rough support for self-extracting ZIP archives. Not an ideal approach, but it works for the archives I've tried. * New "sparsify" option in archive_write_disk converts blocks of nulls into seeks. * Better default behavior for the test harness; it now reports all failures by default instead of coredumping at the first one.
2008-05-26 17:00:24 +00:00
archive_entry_set_mode(ae, S_IFREG | 0600);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
archive_entry_set_size(ae, sizeof(data));
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
assertEqualInt(sizeof(data), archive_write_data(ad, data, sizeof(data)));
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/* Link. */
assert((ae = archive_entry_new()) != NULL);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_pathname(ae, "link3b");
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
archive_entry_set_mode(ae, S_IFREG | 0755);
archive_entry_set_size(ae, sizeof(data));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_hardlink(ae, "link3a");
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
assertEqualInt(sizeof(data), archive_write_data(ad, data, sizeof(data)));
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/*
* Finally, try a new-cpio-like approach, where the initial
* regular file is empty and the hardlink has the data.
*/
/* Regular file. */
assert((ae = archive_entry_new()) != NULL);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_pathname(ae, "link4a");
MFp4: libarchive 2.5.4b. (Still 'b' until I get a bit more feedback, but the 2.5 branch is shaping up nicely.) In addition to many small bug fixes and code improvements: * Another iteration of versioning; I think I've got it right now. * Portability: A lot of progress on Windows support (though I'm not committing all of the Windows support files to FreeBSD CVS) * Explicit tracking of MBS, WCS, and UTF-8 versions of strings in archive_entry; the archive_entry routines now correctly return NULL only when something is unset, setting NULL properly clears string values. Most charset conversions have been pushed down to archive_string. * Better handling of charset conversion failure when writing or reading UTF-8 headers in pax archives * archive_entry_linkify() provides multiple strategies for hardlink matching to suit different format expectations * More accurate bzip2 format detection * Joerg Sonnenberger's extensive improvements to mtree support * Rough support for self-extracting ZIP archives. Not an ideal approach, but it works for the archives I've tried. * New "sparsify" option in archive_write_disk converts blocks of nulls into seeks. * Better default behavior for the test harness; it now reports all failures by default instead of coredumping at the first one.
2008-05-26 17:00:24 +00:00
archive_entry_set_mode(ae, S_IFREG | 0600);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
archive_entry_set_size(ae, 0);
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
MFp4: libarchive 2.5.4b. (Still 'b' until I get a bit more feedback, but the 2.5 branch is shaping up nicely.) In addition to many small bug fixes and code improvements: * Another iteration of versioning; I think I've got it right now. * Portability: A lot of progress on Windows support (though I'm not committing all of the Windows support files to FreeBSD CVS) * Explicit tracking of MBS, WCS, and UTF-8 versions of strings in archive_entry; the archive_entry routines now correctly return NULL only when something is unset, setting NULL properly clears string values. Most charset conversions have been pushed down to archive_string. * Better handling of charset conversion failure when writing or reading UTF-8 headers in pax archives * archive_entry_linkify() provides multiple strategies for hardlink matching to suit different format expectations * More accurate bzip2 format detection * Joerg Sonnenberger's extensive improvements to mtree support * Rough support for self-extracting ZIP archives. Not an ideal approach, but it works for the archives I've tried. * New "sparsify" option in archive_write_disk converts blocks of nulls into seeks. * Better default behavior for the test harness; it now reports all failures by default instead of coredumping at the first one.
2008-05-26 17:00:24 +00:00
#if ARCHIVE_VERSION_NUMBER < 3000000
assertEqualInt(ARCHIVE_WARN, archive_write_data(ad, data, 1));
#else
assertEqualInt(-1, archive_write_data(ad, data, 1));
#endif
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
/* Link. */
assert((ae = archive_entry_new()) != NULL);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_pathname(ae, "link4b");
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
archive_entry_set_mode(ae, S_IFREG | 0755);
archive_entry_set_size(ae, sizeof(data));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
archive_entry_copy_hardlink(ae, "link4a");
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualIntA(ad, 0, archive_write_header(ad, ae));
assertEqualInt(sizeof(data), archive_write_data(ad, data, sizeof(data)));
assertEqualIntA(ad, 0, archive_write_finish_entry(ad));
archive_entry_free(ae);
Fix up test suite so it works again with the libarchive 1.x API. In particular, FreeBSD 6 still uses the libarchive 1.x API and this correction will permit MFCing new libarchive features back to FreeBSD 6.
2008-08-11 01:19:36 +00:00
#if ARCHIVE_VERSION_NUMBER < 2000000
archive_write_finish(ad);
#else
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(0, archive_write_finish(ad));
Fix up test suite so it works again with the libarchive 1.x API. In particular, FreeBSD 6 still uses the libarchive 1.x API and this correction will permit MFCing new libarchive features back to FreeBSD 6.
2008-08-11 01:19:36 +00:00
#endif
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
/* Test the entries on disk. */
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
/* Test #1 */
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assert(0 == stat("link1a", &st));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
/* If the hardlink was successfully created and the archive
* doesn't carry data for it, we consider it to be
* non-authoritive for meta data as well. This is consistent
* with GNU tar and BSD pax. */
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st.st_size, sizeof(data));
assertEqualInt(st.st_nlink, 2);
assert(0 == stat("link1b", &st2));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assertEqualInt(st.st_mode, st2.st_mode);
assertEqualInt(st.st_size, st2.st_size);
assertEqualInt(st.st_nlink, st2.st_nlink);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st.st_ino, st2.st_ino);
assertEqualInt(st.st_dev, st2.st_dev);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
/* Test #2: Should produce identical results to test #1 */
/* Note that marking a hardlink with size = 0 is treated the
* same as having an unset size. This is partly for backwards
* compatibility (we used to not have unset tracking, so
* relied on size == 0) and partly to match the model used by
* common file formats that store a size of zero for
* hardlinks. */
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assert(0 == stat("link2a", &st));
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st.st_size, sizeof(data));
assertEqualInt(st.st_nlink, 2);
assert(0 == stat("link2b", &st2));
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assertEqualInt(st.st_mode, st2.st_mode);
assertEqualInt(st.st_size, st2.st_size);
assertEqualInt(st.st_nlink, st2.st_nlink);
assertEqualInt(st.st_ino, st2.st_ino);
assertEqualInt(st.st_dev, st2.st_dev);
/* Test #3 */
assert(0 == stat("link3a", &st));
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assertEqualInt(st.st_size, sizeof(data));
assertEqualInt(st.st_nlink, 2);
assert(0 == stat("link3b", &st2));
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st2.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st2.st_size, sizeof(data));
assertEqualInt(st2.st_nlink, 2);
assertEqualInt(st.st_ino, st2.st_ino);
assertEqualInt(st.st_dev, st2.st_dev);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
/* Test #4 */
assert(0 == stat("link4a", &st));
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st.st_size, sizeof(data));
assertEqualInt(st.st_nlink, 2);
MfP4: Handle entries with unset size properly: Regular files with unspecified size are "unlimited" (required by Zip reader, which sometimes does not know the uncompressed size of an entry until it gets to the end). Also, hardlinks with unspecified (or zero) size do not overwrite the data on disk nor do they set metadata. This is compatible with GNU tar and NetBSD pax behavior.
2008-09-05 06:13:11 +00:00
assert(0 == stat("link4b", &st2));
Merge from libarchive.googlecode.com: Mostly a bunch of corrections to the Windows support to reconcile differences between Visual Studio and Cygwin. Includes parts of revisions 757, 774, 787, 815, 817, 819, 820, 844, and 886. Of particular note, r886 overhauled the UTF-8/Unicode conversions to work correctly regardless of whether the local system uses 16-bit or 32-bit wchar_t. (I assume that systems with 16-bit wchar_t use UTF-16 and those with 32-bit wchar_t use UCS-4.) This revision also added a preference for wcrtomb() (which is thread-safe) on platforms that support it.
2009-04-12 05:33:34 +00:00
assertEqualInt(st2.st_mode & E_MASK, (S_IFREG | 0755) & ~UMASK);
Issues with hardlinks in newc-format files prompted me to write a new test to exercise the hardlink strategies used by different archive formats (tar, old cpio, new cpio). This uncovered two problems, both fixed by this commit: 1) Enforce file size when writing files to disk. 2) When restoring hardlink entries, if they have data associated, go ahead and open the file so we can write the data. In particular, this fixes bsdtar/bsdcpio extraction of new cpio formats where the "original" is empty and the subsequent "hardlink" entry actually carries the data. It also provides correct behavior for old cpio archives where hardlinked entries have their bodies stored multiple times in the archive; the last body should always be the one that ends up in the final file. The new pax format also permits (but does not require) hardlinks to carry file data; again, the last contents should always win. Note that with any of these, a size of zero on a hardlink simply means that the hardlink carries no data; it does not mean that the file has zero size. A non-zero size on a hardlink does provide the file size. Thanks to: John Baldwin, for reminding me about this long-standing bug and sending me a simple example archive that prompted this test case
2008-01-18 05:05:58 +00:00
assertEqualInt(st2.st_size, sizeof(data));
assertEqualInt(st2.st_nlink, 2);
assertEqualInt(st.st_ino, st2.st_ino);
assertEqualInt(st.st_dev, st2.st_dev);
#endif
}
Reference in New Issue Copy Permalink