On 28/02/20 13:25 +0000, Jonathan Wakely wrote:
These tests were failing on XFS because it doesn't support setting file timestamps past 2038, so the expected overflow when reading back a huge timestamp into a file_time_type didn't happen.Additionally, the std::filesystem::file_time_type::clock has an epoch that is out of range of 32-bit time_t so testing times around that epoch may also fail. This fixes the tests to give up gracefully if the filesystem doesn't support times that can't be represented in 32-bit time_t. * testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for filesystems that silently truncate timestamps. * testsuite/experimental/filesystem/operations/last_write_time.cc: Likewise. Tested powerpc64le-linux and x86_64-linux, on ext4 and XFS.
Huh. I've just noticed that the powerpc64le machine (gcc112) also has XFS, but on that system I can set (and read back) times past the epochalypse. Here's a file on that host: -rw-rw-r--. 1 jwakely jwakely 0 9223372036854775806 filesystem-test.bPba4m-last_write_time Which matches what I get on my machine's tmpfs partition: -rw-rw-r--. 1 jwakely jwakely 0 9223372036854775806 /tmp/filesystem-test.R6DKwt-last_write_time But on my machine's XFS partition the same timestamp gets silently truncated: -rw-rw-r--. 1 jwakely jwakely 0 Jan 19 2038 testsuite/filesystem-test.r8FeLP-last_write_time I don't know how the XFS disk on gcc112 can store 64-bit time stamps when XFS doesn't support them. Odd. Anyway, the patch is committed and I no longer see failures on my XFS disks.
