[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