Re: What is the difference between "Change time" and "Modify time"?

[Theodore Kilgore <kilgota banach math auburn edu>]

On Sun, 31 Jul 2011, Andrew Borodin wrote:

> On Sat, 30 Jul 2011 14:10:41 -0500 (CDT) Theodore Kilgore wrote:
> >
>
> To answer your question, please read the stat(2) man page and find
> description of change time (ctime) and modify time (mtime)
>
> Probably, the built-in help should be more verbose about sort orders.

No joke. 

As to your advice to look up "stat" yes it does seem to help, but it still 
leaves questions about consistent behavior, or the lack thereof, which I 
will describe in more detail below. 

First, here is what the man page says:

"The field st_mtime is changed by file modifications,  for  example,  by
       mknod(2), truncate(2), utime(2) and write(2) (of more than zero 
bytes).
       Moreover, st_mtime of a directory is changed by the creation  or  
dele-
       tion of files in that directory.  The st_mtime field is not changed 
for
       changes in owner, group, hard link count, or mode.

 
       The field st_ctime is changed by writing or by setting  inode  
informa-
       tion (i.e., owner, group, link count, mode, etc.)."

The above says clearly that the mtime data is "changed by the creation of 
deletion of files" whereas nothing is said about that under "ctime." 
Presumably, applying basic logic, the ctime would of course also need 
to be changed (i. e. applied in the first place) if the file is a brand 
new one which previously did not exist, and therefore it might have 
approximately the same effect to sort by ctime under those circumstances 
as to sort by mtime.

Now, here is what is very funny: 

Connecting to an ftp site (ftp.osuosl.org, for example), one might wish to 
look for the new files in a certain directory. To do that, the sensible 
thing is to arrange the files by date of creation. When I tried to do this 
recently from a certain netbook, the "mtime" option produced absolutely no 
visible effect on the file listing, but the "ctime" option did what was 
intended, instead.

I do have to amend something I said yesterday, though. My mistake and I 
apologize. It was not on the ARM netbook that the funny behavior occurred. 
It was on an ASUS eeePC (Intel architecture, and running 
Slackware-current). The intent was to keep current with Slackware-current, 
obviously.

On my regular-sized machines, I have always used the "mtime" option 
previously on simmilar occasions, with no problems, but here it did not 
work, as I said. The only other difference was that my partitions on the 
eeePC are all mounted with the option "noatime" in order to save on writes 
to the SSD devices inside it. But "atime" and "ctime" are not the same 
thing, are they? And furthermore one would expect that to mount physical 
partitions "noatime" would have no influence at all upon the way that 
virtual filesystems get mounted.

For the above reasons, I am still a bit puzzled about what happened, but 
thanks for the information about where to look all this stuff up. The 
explanation in the stat man page is quite clear.

Of course, I could try to reproduce the problem. But for all we know the 
problem might have been a bug in a previous version of MC which was on the 
eeePC prior to the upgrade, or some other package which was causing the 
screwy behavior. So if on testing the problem is not repeatable I guess we 
would never know what caused it. :-/

Theodore Kilgore