stewart@magic.ARPA (Larry Stewart) (01/29/86)
Who looks at file read dates? Do any more-or-less standard Unix applications look at them? Are they worth the trouble of maintaining? For example, a literal interpretation of the semantics of file read dates in Unix would require that the inode for a directory be re-written every time the directory was scanned for a file... Since one can mount a file system read-only, I presume this is not always done. -Larry Stewart Digital Equipment Corporation Systems Research Center
chris@umcp-cs.UUCP (Chris Torek) (01/30/86)
In article <183@magic.ARPA> stewart@magic.UUCP (Larry Stewart) writes: > Who looks at file read dates? Anyone who wants to. > Do any more-or-less standard Unix applications look at them? E.g., ls -l, make: Yes. > Are they worth the trouble of maintaining? Yes. > For example, a literal interpretation of the semantics of file > read dates in Unix would require that the inode for a directory > be re-written every time the directory was scanned for a file... Only the in-core copy need be updated immediately. At sync() or in-core inode reuse, the disk copy needs to be updated. > Since one can mount a file system read-only, I presume this is not > always done. True enough. This is merely a matter of priority: You have to assume that being mounted read-only is more important than having the access times updated. `Them's the breaks.' -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
jerryp@tektools.UUCP (Jerry Peek) (01/31/86)
In article <183@magic.ARPA> stewart@magic.ARPA (Larry Stewart) writes: > Who looks at file read dates? Do any more-or-less standard Unix > applications look at them? Are they worth the trouble of maintaining? One thing that's done on a lot of Tektronix VAXen (and, I've heard, at a lot of sites other places) is a command like this started by cron: find / \( -name '#*' -o -name ',*' \) -atime +3 -print | xargs rm -f & Late at night, it checks for any files whose names start with a comma or pound sign which haven't been read in three days... and zaps them. So, users who want to make a file "temporary" can "remove" it by adding a comma or pound-sign to the start of the name... but they'll be able to get it back within three days if they change their minds. Our MH mail "rmm" command takes advantage of this, fr' instance. Users have also set up "rm"-like commands that add a comma to the filename and "mv" it into to a "to-be-deleted" directory for "cron" to find. [P.S. I posted this instead of mailing directly to Larry because I thought some sites might not have heard of the scheme. It's pretty handy.] --Jerry Peek, Tektronix, Inc. US Mail: MS 74-222, P.O. Box 500, Beaverton, OR 97077 uucp: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp CS,ARPAnet: jerryp%tektools@tektronix.csnet Phone: +1 503 627-1603
jack@boring.uucp (Jack Jansen) (02/01/86)
In article <2952@umcp-cs.UUCP> chris@umcp-cs.UUCP writes: >In article <183@magic.ARPA> stewart@magic.UUCP (Larry Stewart) writes: > >> Who looks at file read dates? > >Anyone who wants to. > >> Do any more-or-less standard Unix applications look at them? > >E.g., ls -l, make: Yes. 'Make' looks at file *read* dates? What does it do that for? I thought make only looked at last update/creation times. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
chris@umcp-cs.UUCP (Chris Torek) (02/02/86)
In article <6756@boring.UUCP> jack@mcvax.UUCP (Jack Jansen) writes: >In article <2952@umcp-cs.UUCP> chris@umcp-cs.UUCP writes: >>In article <183@magic.ARPA> stewart@magic.UUCP (Larry Stewart) writes: >>> Who looks at file read dates? >>E.g., ls -l, make. >'Make' looks at file *read* dates? What does it do that for? Oops, right, sorry about that. (Actually, if I try I might be able to weasel out of this: `make' does a stat() on the file, which gets the access time as well as the mod time. Of course it does not *use* the access time for anything....) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
roy@phri.UUCP (Roy Smith) (02/02/86)
In article <183@magic.ARPA> stewart@magic.ARPA (Larry Stewart) writes: > Who looks at file read dates? Do any more-or-less standard Unix > applications look at them? Are they worth the trouble of maintaining? We use read times for man page cacheing. On 4.2bsd (and others?) the nroff source files for the manual pages are kept in /usr/man/man?/*, with the formated files in /usr/man/cat?/*. When you ask for a man page, man shows you the cat file. If it is missing or out of date w.r.t. the nroff source, man creates it. I have a line in /usr/lib/crontab that finds and removes files in /usr/man/cat?/ that havn't been accessed in 14 days. This strikes a good balance between having all the man pages pre-formated (i.e. eating disk space) and having nroff run every time somebody runs man (sooo sloooow). I don't care when the man page was formated; as long as somebody reads it every other week, it stays around. Many big OS's implement a migrate-to-tape scheme. Files which are not accessed in a certain amount of time are automatically moved from the main system store (i.e. disk) to some other (larger, cheaper, slower) device and a marker left telling where the file went. To implement this on Unix would be fairly easy using file access times. This was discussed a few (6-12?) months ago in net.unix-wizards, I think. As an aside, note that this backup store might be tape, requiring manual intervention to retrieve files, or it might be something else. I understand that there are large (many Gbyte) mass storage devices available (from IBM?) with access times on the order of minutes. -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
hamilton@uiucuxc.CSO.UIUC.EDU (02/05/86)
re: file read times
atime is used by finger (and presumably w) to calculate tty idle time.
i routinely use atime, via ls -lu, for several things, the most useful
of which is to find out if/when someone has read his mail.
wayne hamilton
U of Il and US Army Corps of Engineers CERL
UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801
CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703