GNU bug report logs -
#32289
ls -ltcr and ls -lrt report different modification dates
Previous Next
Full log
Message #10 received at 32289-done <at> debbugs.gnu.org (full text, mbox):
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
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.