[PATCH] libstdc++: Fix FS-dependent filesystem tests
Jonathan Wakely
jwakely@redhat.com
Fri Feb 28 13:38:00 GMT 2020
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.
More information about the Libstdc++
mailing list