GNU bug report logs -
#32289
ls -ltcr and ls -lrt report different modification dates
Previous Next
Full log
View this message in rfc822 format
[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)]
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)]
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.