Subject: bug#32289: closed (Re: bug#32289: ls -ltcr and ls -lrt report different modification dates)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 27 Jul 2018 14:23:02 +0000

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 [email-masked].

-- 
32289: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32289
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#32289: ls -ltcr and ls -lrt report different modification dates
From: Bernhard Voelker <[email-masked]>
To: Ludovic Tolhurst-Cleaver <[email-masked]>, [email-masked]
Date: Fri, 27 Jul 2018 16:22:44 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: ls -ltcr and ls -lrt report different modification dates
From: Ludovic Tolhurst-Cleaver <[email-masked]>
To: [email-masked]
Date: Fri, 27 Jul 2018 10:41:50 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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