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

Attachment: signature.asc
Description: Digital signature

Reply via email to