Some Linux filesystems might not fully support 64 bit timestamps [1],
which make some Linux specific tests to fail when they check for the
functionality.
This patch adds a new libsupport function, support_path_support_time64,
that returns whether the target file supports or not 64 bit timestamps.
The support is checked by issuing a utimensat and verifying both the
last access and last modification time against a statx call.
The tests that might fail are also adjusted to check the file support
as well:
$ dd if=/dev/zero of=loopbackfile.img bs=100M count=1
1+0 records in
1+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0,0589568 s, 1,8 GB/s
$ sudo losetup -fP loopbackfile.img
$ mkfs.xfs loopbackfile.img
meta-data=loopbackfile.img isize=512 agcount=4, agsize=6400 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1
data = bsize=4096 blocks=25600, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=1368, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ mkdir loopfs
$ sudo mount -o loop /dev/loop0 loopfs/
$ sudo chown -R azanella:azanella loopfs
$ TMPDIR=loopfs/ ./testrun.sh misc/tst-utimes
error: ../sysdeps/unix/sysv/linux/tst-utimes.c:55: File loopfs//utimesfECsK1 does not support 64-bit timestamps
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1795576
This patch provides test for utime. It uses wrapper to read access
and modification times to compare them with ones written by utime.
Moreover, access and modification times beyond the Y2038 threshold
date (i.e. 32 bit time_t overflow) are also checked.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>