Touch 2038 problem

1

I was trying to set the change date on a file to well into the future so it always showed up at the top of a sorted list.

The results I get from executing:
touch -d '30 jan 38' aaa.txt
indicates that the file system is incapable of storing dates beyond 18 Jan 2938.

Setting to any date beyond that maximum shows as 19 Jan 2038.

That is somewhat better than a CentOS VM I tried it on which comes up with what look like random dates, and it shows that someone has done some damage limitation but it really needs fixing.

Obviously not an urgent matter.

2

What filesystem do you use at that location?

3

Whatever was installed by default from the downloaded ISO - AlmaLinux 8.6

How can I tell?

4

df -T and report what is in the second column.

5

/dev/mapper/almalinux-root xfs 8370176 3090104 5280072 37% /

6

So the answer to Daca’s question is XFS.

According to Wikipedia (XFS) the supported date range is December 13, 1901 – July 2, 2486. See xfs: widen timestamps to deal with y2038 which describes a patch put in place in 2020.

7

Thank you.

I’m relatively new to the Linux world so I wonder who is responsible for applying that patch? Should not the install iso incorporate such a patch?

8

Someone develops, for example XFS. Red Hat has forked a version of XFS for RHEL 8. Red Hat backports patches to their RHEL 8 branch of XFS. Alma 8 has what RHEL 8 has.

RHEL 8 was released in 2019, so the XFS in it was forked from upstream before that. It is up to Red Hat to incorporate patches. The RHEL 8 will EOL before 2038; support for distant future might not have high priority in it.

In addition to ‘df -T’, there are also lsblk -o name,size,type,fstype,mountpoints and findmnt that can show FSTYPE.

9

Thank you for that and thanks to all for clarifying.

As setting file attribute dates far into the future is not something anyone would normally want to do, I’ll wait patiently for an update :smiley:

10

this all seems very odd to me.

i’ve got a centos 5.11 vm with ext3 that fails but that’s because its a 32-bit install.

i can’t get any other installs of anything else to fail and that includes jfs and ext4 partitions that probably started life on fedora13.

i’ve also got an almalinux 8.7 box that used to run centos with xfs and that works fine too.

are you sure you’re not running a 32-bit install or something (not that there ever was one iirc)? not a raspberry pi or anything odd? what does “uname -a” return? what cpu is it?

if you installed 8.6 then you can “dnf upgrade” to 8.7 but i don’t see that making any difference.

you sure you’re not trying to write to /boot/uefi which will be fat32?

11

I rechecked and got the same results (was also actually running 8.7).

I then decided to upgrade to 9 which I did and that went OK.

Tested again using:

touch -d '1 jan 2400' test.txt

and got

image

I repeated the test using a system folder

cd /opt
touch test.txt
touch -d '1 jan 2401' test.txt
ls -l test.txt
-rw-r--r-- 1 root root 0 Jan 19  2038 test.txt
df -T
Filesystem                 Type     1K-blocks    Used Available Use% Mounted on
devtmpfs                   devtmpfs      4096       0      4096   0% /dev
tmpfs                      tmpfs       906812       0    906812   0% /dev/shm
tmpfs                      tmpfs       362728     612    362116   1% /run
/dev/mapper/almalinux-root xfs        8370176 3123228   5246948  38% /
/dev/sda3                  xfs        1038336  353308    685028  35% /boot
tmpfs                      tmpfs       181360       0    181360   0% /run/user/0
12

As an aside, having upgraded to V9.1, anytime I run dnf (or yum) I get these two SHA1 warnings - even if there is nothing being done.

dnf upgrade
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
Last metadata expiration check: 0:42:59 ago on Mon 13 Feb 2023 05:13:55 GMT.
Dependencies resolved.
Nothing to do.
Complete!
13

The default security policy in el9 does not include SHA1, because it is weak.

Do you have third-party repos that could still use SHA1?

14

This is what I get:

dnf repolist
warning: Signature not supported. Hash algorithm SHA1 not available.
warning: Signature not supported. Hash algorithm SHA1 not available.
repo id                           repo name
appstream                         AlmaLinux 9 - AppStream
baseos                            AlmaLinux 9 - BaseOS
elevate-testing                   ELevate Testing
epel                              Extra Packages for Enterprise Linux 9 - x86_64
extras                            AlmaLinux 9 - Extras
15

Four out of those five I do have and they don’t mention SHA1.
I’d (deep)clean again and test:

dnf --enablerepo=* clean all
dnf --disablerepo=elev* repolist
16

Done that - no change.

Should I remove the 5th one? Which? How?

17

After upgrade the ELevate Testing should not be required, but jlehtone’s answer already covers that.