On 10/13/21 13:57, Bernhard Voelker wrote:
Is it possible that newer touch(1) from coreutils-9.0 supports more of the tricky timestamps which tar-1.34 still fails to grok?
I guess that coreutils was built with 64-bit time_t, but the compiler or development library for some reason doesn't support 64-bit time_t. Perhaps a coreutils/glibc mismatch? You'll need glibc 2.34 or later on platforms like i586 where time_t is traditionally 32-bit but recent Linux kernels have support for 64-bit time_t (this is true for 32-bit x86 and ARM; I don't know about 32-bit PPC).
To pass the tests you can build on a 32-bit-only system, with a coreutils that does not support 64-bit time_t, so that the 'tar' tests don't attempt to try file timestamps past the year 2038.
I suppose we could modify GNU tar's tests so that it doesn't attempt to try these post-2038 timestamps on 32-bit builds. However, it might be better to leave those tests alone, to remind people to be wary of building 32-bit time_t apps with the clock ticking away towards the year 2038 (when these apps will stop working).
Since GNU tar is a core GNU app, I expect that it should use the same year2038 module that coreutils does, to underscore the importance of being year-2038 safe. So I added the year2038 module to the gnulib.modules files of paxutils and tar on Savannah. If you build from bleeding-edge tar and don't want 64-bit time_t, you can configure with --disable-year2038 (though the tests you mention will still fail if coreutils is 64-bit).
