[+Danilo (=downstream maintainer)] Hi Paul,
On 10/13/21 23:58, Paul Eggert wrote: > 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). Thanks for the clarification. We'll exempt that test on those platforms for now. One remark: it seems surprising that `tar -c` succeeds, and only the later `tar -d` complains, because both supposedly do a stat(). I didn't look into the code, so I assume that -c is constraining the values silently into the valid range, doesn't it? Have a nice day, Berny