GNU bug report logs - #75682
ls -l sometimes shows a year in place of the hour and minute

Previous Next

To reply to this bug, email your comments to 75682 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kasia <xo.okasia <at> proton.me>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: ls -l sometimes shows a year in place of the hour and minute
Date: Mon, 20 Jan 2025 01:01:15 +0000

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello Coreutils maintainers,

I believe I've found a bug in the coreutils' ls command.

I was watching a file with watch and ls -l while it was being updated, but sometimes I saw that the time would display a year instead of an hour and minute.

Later I reproduced this issue by doing the following:
- open a terminal emulator
- create two tabs
- run `touch test`
- in tab 1, run
either
while (true); do { ls -l test; }; done;
or
while (true); do { ls -l test | grep -F 2025; }; done;
- in tab 2, run
while (true); do {
 head -c 1 </dev/urandom | grep '[0-9]' | xargs -r -I LENGTH truncate -cs LENGTH test;
}; done;

One tab randomly changes the length of file, while the other shows ls -l of the tile.

In tab 1 I see this:
-rw-r--r-- 1 katarzyna katarzyna 9 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 9 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 9 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 9 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 2 Jan 20  2025 test
-rw-r--r-- 1 katarzyna katarzyna 2 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 2 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 2 Jan 20 00:57 test
-rw-r--r-- 1 katarzyna katarzyna 2 Jan 20 00:57 test

Do you know what might be causing this if it's my system instead of coreutils' ls?

x Kasia
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmeNoEYJkJB2+lKi7Z06RRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmeKB0EiDKo4Q8tcb+sPDcQmtDFjBfOONCanoH3P
zU3VaRYhBOhSZ7P0U35Z9WJN9ZB2+lKi7Z06AACrzQEAg7+S4Y3v8VBJYdRA
3/KlH6A07kxdL8777aXuLGDqdXEA/if94j5pOe7DkpXfqLvK/PgJCvah/SGb
WLUUEVPd9XMD
=jtIB
-----END PGP SIGNATURE-----

[publickey - xo.okasia@proton.me - 0xE85267B3.asc (application/pgp-keys, attachment)]

[publickey - xo.okasia@proton.me - 0xE85267B3.asc.sig (application/pgp-signature, attachment)]

Message #8 received at 75682 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Kasia <xo.okasia <at> proton.me>
Cc: 75682 <at> debbugs.gnu.org
Subject: Re: bug#75682: ls -l sometimes shows a year in place of the hour and
 minute
Date: Sun, 19 Jan 2025 21:17:43 -0800

On 2025-01-19 17:01, Kasia via GNU coreutils Bug Reports wrote:
> Do you know what might be causing this if it's my system instead of coreutils' ls?

It means the file's timestamp is in the future. This can happen if your 
file system's clock is a bit ahead of your kernel's clock. This is not 
uncommon in network file systems.

Of course this sort of thing can lead to problems with programs like 
'make', which rely on file timestamps. You can think of 'ls' as the 
canary in your mineshaft.

Message #11 received at 75682 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Kasia <xo.okasia <at> proton.me>
Cc: 75682 <at> debbugs.gnu.org
Subject: Re: bug#75682: ls -l sometimes shows a year in place of the hour and
 minute
Date: Thu, 23 Jan 2025 11:06:20 +0100

Please give more details:
  - What's the result of
      df -T .
  - What's your libc version?
  - What's the result of
      uname -sr
  - What's the result of
      ls --version

I'm asking because three possible causes come to mind:
  - a network file system (mentioned by Paul Eggert),
  - the multi-grain time stamps introduced in Linux 6.13 [1],
  - a known glibc bug [2] that affects certain coreutils releases.

Bruno

[1] https://www.phoronix.com/news/Linux-6.13-Multigrain-Timestamp
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=30200

Message #14 received at 75682 <at> debbugs.gnu.org (full text, mbox):

From: Kasia <xo.okasia <at> proton.me>
To: "75682 <at> debbugs.gnu.org" <75682 <at> debbugs.gnu.org>
Subject: Re: bug#75682: ls -l sometimes shows a year in place of the hour and
 minute
Date: Sun, 16 Feb 2025 01:54:14 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> df -T .

I was running it under /dev/shm to use a tmpfs.

> - What's your libc version?

2.36

> uname -sr

"Linux 6.1.0-29-amd64"

> ls --version


"ls (GNU coreutils) 9.1"

I'm definitely not using any network file systems.
I don't think I'm running kernel 6.13 or later yet?

The sourceware bugzilla page you linked says, "on glibc 2.30 and older, the time syscall is used if present (which always uses the coarse timer)"

Which does fit what we're seeing here. I'm also seeing this be more likely to trigger on slower machines than my faster machines.

I thought that this was a GNU coreutils bug because the same test using `busybox ls -l` was always giving the hour and time.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmexRTYJkJB2+lKi7Z06RRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmfbSPue5FYrgOEI+41LCfMgbv4WjJBXtpA71Erm
U9yODhYhBOhSZ7P0U35Z9WJN9ZB2+lKi7Z06AAAX6AEA8xcsO7v7d0g0PkPS
7QjlRqIpIYmuVFl5gLYP4Z89KbYA/jA1UBEsLEkJYGQZCuX5CnYKMO7aT+6v
zqCrMVFy5tUI
=DQFV
-----END PGP SIGNATURE-----

Message #17 received at 75682 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Kasia <xo.okasia <at> proton.me>
Cc: 75682 <at> debbugs.gnu.org
Subject: Re: bug#75682: ls -l sometimes shows a year in place of the hour and
 minute
Date: Sat, 15 Feb 2025 21:54:06 -0800

On 2025-02-15 17:54, Kasia via GNU coreutils Bug Reports wrote:

> "Linux 6.1.0-29-amd64"

So this cannot be the multigrain timestamps in Linux 6.13, released 
January 20 and so new that even I'm not running it yet.


> I thought that this was a GNU coreutils bug because the same test using `busybox ls -l` was always giving the hour and time.

This is because busybox ls, contrary to POSIX, acts as though files that 
are in fact dated up to 15 minutes in the future were last modified in 
the past. You can verify the busybox bug as follows:

  $ date
  Sat Feb 15 21:45:10 PST 2025
  $ touch -d'now + 14 minutes' futurefile
  $ ls -l futurefile
  -rw-rw-r-- 1 eggert eggert 0 Feb 15  2025 futurefile
  $ busybox ls -l futurefile
  -rw-rw-r--    1 eggert   eggert           0 Feb 15 21:59 futurefile
  $ date
  Sat Feb 15 21:45:34 PST 2025

Here the busybox behavior is clearly wrong. (Maybe file a bug report to 
the busybox people?)


> "ls (GNU coreutils) 9.1"

So this is quite likely the bug in Linux+glibc that Bruno mentioned, 
where the clock appears to jump backwards by up to 10 ms[1]. Although 
recent versions of coreutils have a workaround, coreutils 9.1 lacks the 
workaround.

Please try upgrading to coreutils 9.6 to fix the 'ls' issue, and be 
aware that other programs may still misbehave on your system since the 
actual bug is below the coreutils level.

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=30200

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.