djfiander@watnot.UUCP (04/11/87)
I just finished reading the MINIX book. It is basically V7 compatible, except
it only stores modification time in the i-nodes (like MS-DOS). This was done
for space reasons. My question is: do any of the usual UNIX utilties/programs
use the creation/access times in a file, or were they just put in because some-
body thought they might be useful?
--
"Are you police officers?"
"No ma'am, we're musicians."
UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!watnot!djfiander
CSNET : djfiander%watnot@waterloo.CSNETchris@mimsy.UUCP (04/19/87)
In article <12854@watnot.UUCP> djfiander@watnot.UUCP writes: >... do any of the usual UNIX utilties/programs use the creation/access >times in a file, or were they just put in because somebody thought they >might be useful? Some things do indeed use the access times. For example, we keep preformatted copies of `high demand' manual entries by removing those that prove not to be high-demand: find /usr/man/cat? -atime +5 -exec rm -f {} \; As for the other, it is not a creation time: ctime stands for `change time'. It is used to determine which files must be put onto backup tapes, hence is very important in larger installations. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
mangler@cit-vax.Caltech.Edu (System Mangler) (04/19/87)
In article <12854@watnot.UUCP> djfiander@watnot.UUCP writes: >... do any of the usual UNIX utilties/programs use the creation/access >times in a file [...]? The undocumented "-v" option to 4.[23] BSD /etc/quot lists the number of kilobytes not accessed in 30, 60, 90 days. This is useful when pleading with self-righteous users to clean out their deadwood. It would be even more valuable if it summarized far longer access times (for the highly self-righteous types who use 80% of the disk space and cannot be cajoled/coerced to delete anything accessed within the last 500 days). The change time (st_ctime) is used only by /etc/dump. Neither atime nor ctime is useful if you do backups with "tar", since tar accesses all the files. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
djfiander@watmath.UUCP (04/19/87)
In article <6362@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <12854@watnot.UUCP> djfiander@watnot.UUCP writes: >>... do any of the usual UNIX utilties/programs use the creation/access >>times in a file, or were they just put in because somebody thought they >>might be useful? > >As for the other, it is not a creation time: ctime stands for >`change time'. It is used to determine which files must be put >onto backup tapes, hence is very important in larger installations. In that case, what is the difference between ctime and mtime? According to <sys/inode.h> mtime is last modification time and ctime is last inode change time. When would one change, and not the other? -- "Are you police officers?" "No ma'am, we're musicians." - The Blues Brothers UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!djfiander CSNET : djfiander%watmath@waterloo.CSNET
pdb@sei.cmu.edu (Patrick Barron) (04/20/87)
In article <12905@watmath.UUCP> djfiander@watmath.UUCP (David Fiander) writes: >In that case, what is the difference between ctime and mtime? According to ><sys/inode.h> mtime is last modification time and ctime is last inode change >time. When would one change, and not the other? Changes to the contents of a file will update both ctime and mtime. If you do something that only changes the file's inode (like changing the permissions of a file), then only ctime is updated. --Pat.
john@xanth.UUCP (04/21/87)
In article <12905@watmath.UUCP>, djfiander@watmath.UUCP writes: > In that case, what is the difference between ctime and mtime? According to > <sys/inode.h> mtime is last modification time and ctime is last inode change > time. When would one change, and not the other? The mtime changes whenever the contents of the file change; on a creat() call or equivalent, or on a write() call. The ctime changes whenever the inode information changes: chown, chmod, link, unlink, etc. (This means that mv'ing the file changes the ctime, at least twice....) Of course writing to the file will change the ctime too (although I'm not sure if writing to the file without changing the size does - anyone not too lazy to try it or look in a kernel). The only exception I know of is that updating the access time doesn't change the ctime (!). -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
mangler@cit-vax.Caltech.Edu (System Mangler) (04/26/87)
In article <861@xanth.UUCP>, john@xanth.UUCP (John Owens) writes: > [...] mv'ing the file changes the ctime, [...] Does anything other than /etc/dump look at the ctime? (Don't mention rogue's check for saved-game fraud). If not, then there is no need for link(), unlink(), and rename() to change the ctime, since any such operation necessarily updates a directory, which should be enough information for /etc/restore, without needing to clutter the dump tape with the unchanged contents of the renamed file. Historically, restor [sic] wanted to have the inode on the tape to make sure the link count got updated. Even if the link count didn't get adjusted, fsck routinely fixes those. With restor (almost) gone, perhaps this behaviour is no longer useful. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
jerry@oliveb.UUCP (Jerry F Aguirre) (05/13/87)
In article <12854@watnot.UUCP> djfiander@watnot.UUCP (David Fiander) writes: >I just finished reading the MINIX book. It is basically V7 compatible, except >it only stores modification time in the i-nodes (like MS-DOS). This was done >for space reasons. My question is: do any of the usual UNIX utilties/programs >use the creation/access times in a file, or were they just put in because some- >body thought they might be useful? Aside from the cleaning up of unused files mentioned by others there is one utility not mentioned, mail! Mail uses a comparison of changed and accessed times to decide whether you have "NEW" mail. Not a vital service but it is used.
davy@pur-ee.UUCP (Dave Curry) (05/23/87)
>In article <12854@watnot.UUCP> djfiander@watnot.UUCP (David Fiander) writes: >I just finished reading the MINIX book. It is basically V7 compatible, except >it only stores modification time in the i-nodes (like MS-DOS). This was done >for space reasons. My question is: do any of the usual UNIX utilties/programs >use the creation/access times in a file, or were they just put in because some- >body thought they might be useful? > Yes. "dump" uses the inode change time (it is *not* the creation time) to decide what to dump to tape. Not having it and not storing modification times on the disk would make partial dumps basically impossible, at least under the current scheme. Access time, as previously mentioned, is used for the "mail"/"new mail" hack. It is also used to determined idle time by finger, w, etc. One other thing it's useful for is to see if a program has been executed -- "ls -lu file" is a great way for debugging things like inetd when they act up. (For those of you who don't follow, executing a program updates its access time. For those of you completely in the dark, the secret's to bang the rocks together, guys.) Storing the modification time only in memory is cute I suppose, but probably makes the "make" utility rather useless after rebooting the system... Somehow recompiling the entire kernel every time when debugging something new just doesn't turn me on... 'Course, I suppose MINIX compiles a little quicker than 4.3BSD, so maybe it isn't a big deal. --Dave Curry