GNU bug report logs - #32289
ls -ltcr and ls -lrt report different modification dates

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32289 in the body.
You can then email your comments to 32289 AT debbugs.gnu.org in the normal way.

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

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

From: Ludovic Tolhurst-Cleaver <ludovic.tolhurst-cleaver <at> sabstt.com>
To: bug-coreutils <at> gnu.org
Subject: ls -ltcr and ls -lrt report different modification dates
Date: Fri, 27 Jul 2018 10:41:50 +0100

Dear GNU folks

I believe I have found a bug in ls in the GNU coreutils v. 8.22.

My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB).

In the full listing we saw that date next to a different file in the other listing.

`ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`.


$ ls -ltcr ludo*

-rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz

$ ls -lrt ludo*

-rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz


I'm afraid I do not have the capability to test this on any later version of the coreutils.

Thanks & regards

Ludo Tolhurst-Cleaver
Perl Developer
SABS TT

Message #10 received at 32289-done <at> debbugs.gnu.org (full text, mbox):

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Ludovic Tolhurst-Cleaver <ludovic.tolhurst-cleaver <at> sabstt.com>,
 32289-done <at> debbugs.gnu.org
Subject: Re: bug#32289: ls -ltcr and ls -lrt report different modification
 dates
Date: Fri, 27 Jul 2018 16:22:44 +0200

tag 32289 notabug
close 32289
thanks

On 07/27/2018 11:41 AM, Ludovic Tolhurst-Cleaver wrote:
> Dear GNU folks
> 
> I believe I have found a bug in ls in the GNU coreutils v. 8.22.
> 
> My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB).
> 
> In the full listing we saw that date next to a different file in the other listing.
> 
> `ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`.
> 
> 
> $ ls -ltcr ludo*
> 
> -rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz
> 
> $ ls -lrt ludo*
> 
> -rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz
> 
> 
> I'm afraid I do not have the capability to test this on any later version of the coreutils.
> 
> Thanks & regards
> 
> Ludo Tolhurst-Cleaver
> Perl Developer
> SABS TT

'ls' prints the modification (mtime) per default, while -c asks to display the ctime,
i.e., the time of the last status change:

  $ ls --help | grep -A3 -F -- ' -c '
    -c                         with -lt: sort by, and show, ctime (time of last
                                 modification of file status information);
                                 with -l: show ctime and sort by name;
                                 otherwise: sort by ctime, newest first

  $ touch file

  $ touch -m -d yesterday file

  $ stat file
    File: file
    Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
  Device: 820h/2080d	Inode: 540222      Links: 1
  Access: (0644/-rw-r--r--)  Uid: (  717/voelkerb)   Gid: ( 1000/voelkerb)
  Access: 2018-07-27 16:11:13.073491312 +0200
  Modify: 2018-07-26 16:11:32.953193672 +0200
  Change: 2018-07-27 16:11:32.945894976 +0200
   Birth: -

  $ ls -log file
  -rw-r--r-- 1 0 Jul 26 16:11 file

  $ ls -logc file
  -rw-r--r-- 1 0 Jul 27 16:11 file

So choosing the options according to one's initials doesn't seem to be
a good choice, or at least display other data than you might expect. ;-)

As this is not a bug in 'ls', I'm marking it as such in our bug tracker.
Of course, you can still continue the discussion by simply replying.

Have a nice day,
Berny

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

From: Ludovic Tolhurst-Cleaver <ludovic.tolhurst-cleaver <at> sabstt.com>
To: 32289 <at> debbugs.gnu.org
Subject: Fwd: Fwd: Fwd: ls -ltcr and ls -lrt report different modification
 dates
Date: Fri, 27 Jul 2018 14:10:59 +0100

-------- Forwarded Message --------

Apologies again folks: ls -ltc and ls -lt output different information
by design.

Please forgive me wasting your time.

L.



-------- Forwarded Message --------

Apologies - here is the OS information:

$ cat /proc/version
Linux version 3.10.0-862.3.3.el7.x86_64
(builder <at> kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat
4.8.5-28) (GCC) ) #1 SMP Fri Jun 15 04:15:27 UTC 2018

Many thanks
LTC

-------- Forwarded Message --------

Dear GNU folks

I believe I have found a bug in ls in the GNU coreutils v. 8.22.

My colleague and I found that 'ls' reported a different date for a gzipped log file when run with different options in a directory containing a large amount of data (1000MB).

In the full listing we saw that date next to a different file in the other listing.

`ls -ltcr` seems to be the one showing the correct date here. I like to use `ls -ltc` because it's my initials. My colleague was running `ls -lrt`.


$ ls -ltcr ludo*

-rw-rw-rw- 1 pax pax 237817 Jul 20 06:53 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz

$ ls -lrt ludo*

-rw-rw-rw- 1 pax pax 237817 Jul 18 12:30 ludovic.tolhurst-cleaver_sabstt.com-log-20180720.gz


I'm afraid I do not have the capability to test this on any later version of the coreutils.

Thanks & regards

Ludo Tolhurst-Cleaver
Perl Developer
SABS TT

Previous Next

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