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

Previous Next

Package: coreutils;

Reported by: Ludovic Tolhurst-Cleaver <ludovic.tolhurst-cleaver <at> sabstt.com>

Date: Fri, 27 Jul 2018 12:33:01 UTC

Severity: normal

Merged with 32292

Done: Bernhard Voelker <mail <at> bernhard-voelker.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Ludovic Tolhurst-Cleaver <ludovic.tolhurst-cleaver <at> sabstt.com>
Subject: bug#32289: closed (Re: bug#32289: ls -ltcr and ls -lrt report
 different modification dates)
Date: Fri, 27 Jul 2018 14:23:02 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#32289: ls -ltcr and ls -lrt report different modification dates

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 32289 <at> debbugs.gnu.org.

-- 
32289: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32289
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 part 3 (message/rfc822, inline)]
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




This bug report was last modified 6 years and 210 days ago.

Previous Next


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