--- Begin Message ---
|
Subject: |
ls -ltcr and ls -lrt report different modification dates |
|
Date: |
Fri, 27 Jul 2018 10:41:50 +0100 |
|
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#32289: ls -ltcr and ls -lrt report different modification dates |
|
Date: |
Fri, 27 Jul 2018 16:22:44 +0200 |
|
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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
--- End Message ---