This bug seems to only occur for the posix format tar archives. It's repeatable outside the tar test suite by doing:
---- #!/bin/sh export TAR_OPTIONS="-H posix --pax-option=exthdr.name=%d/PaxHeaders/%f" echo hello > file1 echo goodbye > file2 while :; do tar cf archive.1 file1 file2 tar cfT archive.2 /dev/null tar rf archive.2 file1 tar rf archive.2 file2 if cmp archive.1 archive.2 >/dev/null; then echo -n . else echo -n + fi done ---- The output should be all dots if the assumptions of the test are correct, but I get: +.......+..........................................+.................... ......................++.........................................++..... .....................................+.................................. .......+................................................................ .............................................................+.......... ...............................+........................................ .+.........................................+............................ Which is to say it fails about 3% of the time on my system (stable over about 2000 iterations). I'd say that warrants downgrading this bug from serious. The fundamental problem seems to be that the POSIX format tarballs include the atime of the files in the archive (which may change between adding the file to the first archive and the second), and the mtime of the archive itself (which likewise may change). I don't see any way to work around that, though -- "--atime-preserve" helps (by eliminating the atimes), but that still leaves it failing around 1.7% of the time (when the mtimes don't match, presumably). If the test is run on a filesystem that preserves timestamps to the nanosecond (or possibly even the microsecond?), this test will always fail. Cheers, aj
signature.asc
Description: Digital signature