joe@dual.UUCP (Joe Weinstein) (08/21/86)
Hi. I'm wondering how many UNIX's give the commands % ls -l and % ls -lc the same result for a file that had been modified some time after creation, in such a way that the inode block list didn't change? The c option is supposed to give the inode modification date instead of the file modification date. One has to define "inode modification" use- fully because even cat'ing a file modifies the inode access time field. I think the best definition for inode modification is inode creation, so that we have a good indicator of file creation date. On our V.2.2, ls -l == ls -lc, though I have jimmied my own kernel to to what I think it should. Does yours? What do you think?
guy@sun.uucp (Guy Harris) (08/22/86)
> I'm wondering how many UNIX's give the commands > > % ls -l and % ls -lc > > the same result for a file that had been modified > some time after creation, in such a way that the > inode block list didn't change? Only ones that have been broken. > The c option is supposed to give the inode > modification date instead of the file modification > date. One has to define "inode modification" use- > fully because even cat'ing a file modifies the inode > access time field. I think the best definition for > inode modification is inode creation, so that we > have a good indicator of file creation date. Oh, PLEASE, no! Creating an inode hardly "modifies" it; if it wasn't there to begin with, how can you modify it? Let's not encourage people to read the "c" in "ctime" as "creation"; we have enough people misreading it that way already! There is a VERY SPECIFIC purpose for the inode change time. It is there so that dump programs can dump an inode if its attributes have changed, even if the actual data in the file belonging to that inode have not changed. If the change time were made into a creation time, changing the permissions on an inode would not mark the inode as changed in any way, so a dump program wouldn't know that this change should be recorded on a dump tape. How useful is the creation time anyway? If you *really* need it, consider picking up the 4.2BSD file system; there is some spare room in the inode (and the "stat" structure) for a creation time. Make sure you really *can't* do without it, though, since you may end up eating up all the spare space and then find you need it for something more important than a creation time (there's only room in the "stat" structure for one more time, if you include the spare longword for holding fractional seconds).... It may be peculiar that the time of last access is not considered an attribute, so that changing it doesn't change the inode change time. On the other hand, the time of last access also isn't updated 1) when a directory is searched or 2) if the file is on a read-only file system, so the time of last access is more of a hint than a guarantee. > On our V.2.2, ls -l == ls -lc, Then why didn't you throw away the "ctime" field in the inode, copy the "mtime" field into the "stat" structure's "ctime" field when you do a "stat", and use the four bytes (8 bytes, if you use the 4.2 file system) freed for something useful? > though I have jimmied my own kernel to to what I think it > should. > Does yours? What do you think? Ours doesn't, and I think you should have left well enough alone. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)