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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#32289: closed (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 message dated Fri, 27 Jul 2018 16:22:44 +0200
with message-id <76da2469-50e6-2b30-78f7-48bd9158af59 <at> bernhard-voelker.de>
and subject line Re: bug#32289: ls -ltcr and ls -lrt report different modification dates
has caused the debbugs.gnu.org bug report #32289,
regarding ls -ltcr and ls -lrt report different modification dates
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> 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: 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 part 3 (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

Previous Next

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