Good guess, but I don't think that explains anything, since
the order in which hardlinked files get stored doesn't matter.
(There are a few tests that do detailed format verification;
those would be affected by the order in which files get stored,
but none of those depend on the ordering of readdir().)
The reference to 92-characters in that test refers to the length
of the filename not including the directory portion.
(Details: "original/" is 9 characters, the link length limit for
ustar is 100 characters, and the test code only verifies the
final path element, hence should never see anything over 91
chars; I should probably put some more detailed comments around
that part of the test code.)
Have you had a chance to try the libarchive 2.5.3b package?
I've fixed a subtle issue with handling almost-too-long filenames
in ustar format (which doesn't appear to explain the problems
you're having) and also reworked a couple of the tests to give
more information. Maybe that would shed additional light on
this problem.
I've also just committed a change to the test_format_newc code
that allows for a 1-second slop in that test, which should eliminate
the occasional failure you mentioned. Thanks for reporting that.
Cheers,
Tim
Bernhard R. Link wrote:
I think I found the problem:
# tar -tvvf ustar/archive 2>&1 | grep
'original/f_abcdefghijklmnopqrstuvwxyzabcdefghijkl '
says:
hrw-r--r-- brl/brl 0 2008-05-11 11:41
original/f_abcdefghijklmnopqrstuvwxyzabcdefghijkl link to
original/l_abcdefghijklmnopqrstuvwxyzabcdefghijkl
This is the file with 92 characters, which is (as far as I understand
test_copy.c:111) not expressable as link.
I guess the reason for this is that depending on the filesystem options
readdir returns the prior created files in some random order, so
sometimes l_* gets returned before f_* (judging from the Debian buildds,
on Linux actually more often than not). And thus the test-case fails.
Hochachtungsvoll,
Bernhard R. Link
By the way, I think there is also a race condition in
cpio/test/test_format_new.c in test_format_newc. In one run
one of the "assertEqualInt(t, from_hex(e + 46, 8));" failed for me with
two number differing by one. (I guess some the second stepped just as
the wrong moment). Dunno if that is important enough to fix, as seldom
as it seems to happen.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
