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 _______________________________________________ mc mailing list http://mail.gnome.org/mailman/listinfo/mc