m5@lynx.UUCP (Mike McNally ) (04/26/88)
I am trying to convince some of my ``colleagues'' here that keeping track of last-access times of files is a useful pursuit for an operating system. The only good reasons I can come up with are 1. it's nice for accounting/housekeeping 2. it's a useful security feature (has anyone looked at my database since I left yesterday?) Are these reasons enough to justify the overhead (I think so)? Are there other reasons that I am overlooking? -- Mike McNally of Lynx Real-Time Systems uucp: lynx!m5 (maybe pyramid!voder!lynx!m5 if lynx is unknown)
friedl@vsi.UUCP (Stephen J. Friedl) (04/26/88)
In article <3672@lynx.UUCP>, m5@lynx.UUCP (Mike McNally ) writes: > I am trying to convince some of my ``colleagues'' here that keeping track > of last-access times of files is a useful pursuit for an operating system. > [...] > Are these reasons enough to justify the overhead (I think so)? Are there > other reasons that I am overlooking? Starting on a related topic: I believe the access time of a UNIX file must be updated after each read (not just at the open). Since mounting a filesystem readonly turns this update mechanism off because the inode is not writable, I would assume that this would speed up a filesystem slightly: does anybody have any experience on this? -- Steve Friedl V-Systems, Inc. Spaf for president! friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl
tli@sargas.usc.edu (Tony Li) (04/26/88)
In article <3672@lynx.UUCP> m5@lynx.UUCP (Mike McNally (Man from Mars)) writes:
I am trying to convince some of my ``colleagues'' here that keeping track
of last-access times of files is a useful pursuit for an operating system.
The only good reasons I can come up with are
1. it's nice for accounting/housekeeping
2. it's a useful security feature (has anyone looked at my database
since I left yesterday?)
Here's one example of #1 which I hope proves sufficient in and of
itself.
We keep a single pack here which we use to maintain sources for our
Unix system. With comp.sources.misc, comp.sources.unix, alt.sources,
etc., this disk gets full rather rapidly. By looking at the access
times, we can determine if a particular source file has been examined
recently. If it has been touched 'recently', then someone has been
looking at it and we should probably leave it around. Of course, this
is an implicit assumption of temporal locality. If a file has not
been accessed recently, then it is probably not necessary in the near
future. We can then either compress the file or archive it to tape.
I've seen similar schemes on Tops-20 which will archive a users files
in an attempt to minimize disk usage.
Tony Li - USC University Computing Services - Dain Bramaged.
Uucp: oberon!tli
Bitnet: tli@uscvaxq, tli@ramoth
Internet: tli@sargas.usc.eduswh@hpsmtc1.HP.COM (Steve Harrold) (04/26/88)
Re: file timestamp of last use Another use is to provide data for file archiving programs. Files not recently used can be migrated to cheaper storage media. --------------------- Steve Harrold ...hplabs!hpsmtc1!swh HPG200/13 (408) 447-5580 ---------------------
raveling@vaxa.isi.edu (Paul Raveling) (04/27/88)
In article <3672@lynx.UUCP> m5@lynx.UUCP (Mike McNally (Man from Mars)) writes: >I am trying to convince some of my ``colleagues'' here that keeping track >of last-access times of files is a useful pursuit for an operating system. >... >Are these reasons enough to justify the overhead (I think so)? Are there >other reasons that I am overlooking? 1. Automatic file archiving (archive to tape [or whatever] if a file has not been accessed within the last n weeks) -- Helps lots, particularly on multi-user systems with marginal amounts of disk space. 2. Manual identification of files that have been forgotton -- On Tenex I frequently got directory listings in reverse chronological order by access time for precisely this purpose. 3. Checking for surprises -- for example, finding that half of your Lisp modules are being loaded from source and interpreted instead of being loaded from compiled files. 4. Security checks. Something else I used to do occasionally on Tenex was to use directory listings to check for surprises in WHO had last read my files. (Do any current systems keep track of the identities of the file's creator, last writer, and last reader?) --------------------- Paul Raveling Raveling@vaxa.isi.edu
rpd@cs.cmu.edu (Richard Draves) (04/27/88)
Hmm, Vice doesn't keep track of the last-access time for a file, only the modified time. (If you stat() a Vice file, the mtime, ctime, and atime are always the same.) The rationale is that if a client writes a file, it has to talk to the server anyway to communicate the new data, so it doesn't extra to update the modified time. However, updating the access-time would require the client to talk to the server when the client tries to read a cached file. The current Vice implementation goes to great lengths to unburden the servers, and this was considered unacceptable. Rich
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (04/28/88)
In article <3672@lynx.UUCP> m5@lynx.UUCP (Mike McNally (Man from Mars)) writes: | I am trying to convince some of my ``colleagues'' here that keeping track | of last-access times of files is a useful pursuit for an operating system. | The only good reasons I can come up with are | | 1. it's nice for accounting/housekeeping DLA is as important as DLM for system management. It can be used to identify files not frequently used and make them candidates for removal to an archive (or bit bucket). I use it to determine if files on a BBS are of interest to users, and to identify files on any system I use which should be moved to other storage. If your colleagues don;t see DLA, what use can they find for DLM. Both are for housekeeping of one type or another. | 2. it's a useful security feature (has anyone looked at my database | since I left yesterday?) That's stretching. You could do it, but (a) would you bother, (b) would the user remember the last time the db was used, and (c) does it really provide mush security? If you need that level of security, build a "file access" audit trail into the kernel. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
jgy@hropus.UUCP (John Young) (04/28/88)
> In article <3672@lynx.UUCP>, m5@lynx.UUCP (Mike McNally ) writes: > > I am trying to convince some of my ``colleagues'' here that keeping track > > of last-access times of files is a useful pursuit for an operating system. > > [...] > > Are these reasons enough to justify the overhead (I think so)? Are there > > other reasons that I am overlooking? > > Starting on a related topic: > > I believe the access time of a UNIX file must be updated after > each read (not just at the open). Since mounting a filesystem > readonly turns this update mechanism off because the inode is not > writable, I would assume that this would speed up a filesystem > slightly: does anybody have any experience on this? > > -- > Steve Friedl V-Systems, Inc. Spaf for president! > friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl The time spent doing this is minimal. The inode is in-core and being accessed anyway. The "overhead" is simply the assignment: iptr->a_time = lbolt; (or whatever the clock/time is) This is done regardless of whether or not the fs is mounted readonly. (not worth the effort to check I suppose). There is no need to ever write the inode to disk until the "access" is finished with (final close) so that't the only time when you'll get that modest saving. John Young
DGD@cup.portal.com (04/28/88)
The most useful aspect of "access time" is for a system administrator.
I was once so unfortunate as to be on a large system where the users
woould squirrel away copies of large programs (.c's .o's .a's ,etc.)
and very rarely use them. When the disk crunch hit, as it had to, a simple
"find" of files not accessed for 6 months showed about 200 megabytes
of files which were candidates for purging/backup-to-tape/whatever.
"If you haven't used it for 6 months, you don't need it on-line!"bader+@andrew.cmu.edu (Miles Bader) (04/28/88)
3. Vanity. Has anyone read my .plan file lately?
avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) (04/30/88)
In article <4876@cup.portal.com>, DGD@cup.portal.com writes: > The most useful aspect of "access time" is for a system administrator. > I was once so unfortunate as to be on a large system where the users > woould squirrel away copies of large programs (.c's .o's .a's ,etc.) > and very rarely use them. When the disk crunch hit, as it had to, a simple > "find" of files not accessed for 6 months showed about 200 megabytes > of files which were candidates for purging/backup-to-tape/whatever. > "If you haven't used it for 6 months, you don't need it on-line!" Unfortunately, "access time" is NOT updated when an executable is executed. I was once on a system whose very clever administrator wrote a demon to archive any file not "accessed" in the last month. He soon archived an executable I was exec'ing every day from my .profile. The only way to restore an archived file was from one's own shell - and since my .profile was bombing, I could not get one. I finally managed to move the .profile after su'ing from a friend's login. I then retrieved the missing executables, and put in code to touch all my executables periodically. Ugh. Adam Reed (mtgzz!avr)
jc@minya.UUCP (John Chambers) (05/02/88)
One of my more common uses is to ask when some program was
last executed. Common programs for which I wish to know
this are uucico, uux, rnews, etc. Sometimes I can finger
email problems by observing that some program hasn't been
run since last Tuesday, so the problem must be with cron
or some such culprit.
As a special case, it is often hard to determine which of
several alternatives with the same name (which can easily
happen on a Sun with lots of NFS clients) cron has run.
Waiting for the program to run, and checking the access
times is a simple way to answer the question. Very often,
the answer is surprising.
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
You can't make a turtle come out.
-- Malvina Reynoldsmike@turing.UNM.EDU (Michael I. Bushnell) (05/05/88)
In article <4054@mtgzz.UUCP> avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: >Unfortunately, "access time" is NOT updated when an executable is >executed. [Sad story deleted] Put this down to YATBF (Yet Another Thing Berkeley Fixed). On BSD 4.3, execve properly updates the access time. N u m q u a m G l o r i a D e o Michael I. Bushnell HASA - "A" division 14308 Skyline Rd NE Computer Science Dept. Albuquerque, NM 87123 OR Farris Engineering Ctr. OR University of New Mexico mike@turing.unm.edu Albuquerque, NM 87131 {ucbvax,gatech}!unmvax!turing.unm.edu!mike
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (05/05/88)
In article <4054@mtgzz.UUCP> avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: >Unfortunately, "access time" is NOT updated when an executable is >executed. I was once on a system whose very clever administrator wrote a >demon to archive any file not "accessed" in the last month. He soon >archived an executable I was exec'ing every day from my .profile. I tried this on several systems, and it seems that you are correct for BSD (at least the Ultrix and SunOS versions), but not for SysV (again at least Xenix and 2B2/300 flavors). I'm glad you pointed this out, since I do just what you mention on my machine (SysV). -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
guy@gorodish.Sun.COM (Guy Harris) (05/06/88)
> I tried this on several systems, and it seems that you are correct for > BSD (at least the Ultrix and SunOS versions), but not for SysV (again at > least Xenix and 2B2/300 flavors). I tried it on a 3B2/400 running S5R3.1 and the access time *is* updated when you run a program; it should be, since I consider running a program to count as an "access". Maybe the releases you were running were broken, or maybe older versions of UNIX didn't do this but somebody thought better of it later?
john@jetson.UUCP (John Owens) (05/06/88)
In article <4054@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > Unfortunately, "access time" is NOT updated when an executable is > executed. Interesting! It certainly is updated on SCO Xenix ("System V", but internals still have v7 vestiges), v7, 4.2BSD, and 4.3BSD. Is it not updated on execution under "real" System V? What OS version are you (mtgzz!avr) running? -- John Owens SMART HOUSE Development Venture john@jetson.UUCP (old uucp) uunet!jetson!john +1 301 249 6000 (internet) john%jetson.uucp@uunet.uu.net
raveling@vaxa.isi.edu (Paul Raveling) (05/06/88)
In article <10730@steinmetz.ge.com> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: >In article <4054@mtgzz.UUCP> avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > >>Unfortunately, "access time" is NOT updated when an executable is >>executed. I was once on a system whose very clever administrator wrote a >>demon to archive any file not "accessed" in the last month. He soon >>archived an executable I was exec'ing every day from my .profile. > >I tried this on several systems, and it seems that you are correct for >BSD (at least the Ultrix and SunOS versions), but not for SysV (again at >least Xenix and 2B2/300 flavors). I'm glad you pointed this out, since I >do just what you mention on my machine (SysV). Another system: HP-UX (version 5.5) DOES update last-access time on executing a file. --------------------- Paul Raveling Raveling@vaxa.isi.edu
kolding@ji.Berkeley.EDU (Eric Koldinger) (05/08/88)
>>>Unfortunately, "access time" is NOT updated when an executable is >>>executed. I was once on a system whose very clever administrator wrote a >>>demon to archive any file not "accessed" in the last month. He soon >>>archived an executable I was exec'ing every day from my .profile. >> >>I tried this on several systems, and it seems that you are correct for >>BSD (at least the Ultrix and SunOS versions), but not for SysV (again at >>least Xenix and 2B2/300 flavors). I'm glad you pointed this out, since I >>do just what you mention on my machine (SysV). I hate to disagree with you, but 4.3 BSD does update the access time when a program is executed. I just checked /usr/local/rn with an ls -lu, and I got the following: -rwxr-xr-x 1 root 137216 May 7 11:59 /usr/local/rn and the date right now is (according to date): Sat May 7 12:04:41 PDT 1988 so I'd say if got touched when I fired up this process up. Perhaps you've been checking on read only file systems, or perhaps the program wasn't working right and archiving files that hadn't been changed in a while. _ /| Eric \`o_O' kolding@ji.berkeley.edu ( ) "Gag Ack Barf" {....}!ucbvax!ji!kolding U
levy@ttrdc.UUCP (Daniel R. Levy) (05/08/88)
In article <4054@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > Unfortunately, "access time" is NOT updated when an executable is > executed. You should qualify your statement with "not ALWAYS updated", unless you specify a specific system. This machine obviously updates access time upon execution: $ ls -ul /bin/cat -rwxrwxr-x 1 bin bin 10356 May 7 20:38 /bin/cat $ ls -ul /bin/cat -rwxrwxr-x 1 bin bin 10356 May 7 20:38 /bin/cat $ /bin/cat /etc/TIMEZONE TZ=CDT5 export TZ $ ls -ul /bin/cat -rwxrwxr-x 1 bin bin 10356 May 7 20:42 /bin/cat $ uname -a ttrdc ttrdc 2.0v3 1208 3B-20S Gurus: Which systems DO update access time upon execution (presuming it's possible at all, e.g., not on a readonly filesystem)? Which systems don't? -- |------------Dan Levy------------| Path: ihnp4,<most AT&T machines>!ttrdc!levy | AT&T | Weinberg's Principle: An expert is a | Data Systems Group | person who avoids the small errors while |--------Skokie, Illinois--------| sweeping on to the grand fallacy.
wnp@dcs.UUCP (Wolf N. Paul) (05/08/88)
In article <40@jetson.UUCP> john@jetson.UUCP (John Owens) writes: >In article <4054@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: >> Unfortunately, "access time" is NOT updated when an executable is >> executed. > >Interesting! It certainly is updated on SCO Xenix ("System V", but >internals still have v7 vestiges), v7, 4.2BSD, and 4.3BSD. Is it >not updated on execution under "real" System V? What OS version are >you (mtgzz!avr) running? Access time IS updated on real System V when a binary or shell script is executed. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: ihnp4!killer!dcs!wnp ESL: 62832882 INTERNET: wnp@DESEES.DAS.NET or wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD
rroot@edm.UUCP (uucp) (05/08/88)
From article <40@jetson.UUCP>, by john@jetson.UUCP (John Owens): > In article <4054@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: >> Unfortunately, "access time" is NOT updated when an executable is >> executed. > > Interesting! It certainly is updated on SCO Xenix ("System V", but It is also updated on an IRIS (mostly sysV with a BSD file system). I know, because of a typo in crontab that resulted in the removal of all files with an atime <1day. It took a couple of hurs to figure out what was wrong because all of the 'necessary' binaries & data files were still there (thank god I'd used tar that day... :-] ) -- ------------- Stephen Samuel {ihnp4,ubc-vision,vax135}!alberta!edm!steve or userzxcv@uqv-mts.bitnet
avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) (05/10/88)
In article <2651@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: > In article <4054@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > > Unfortunately, "access time" is NOT updated when an executable is > > executed. > You should qualify your statement with "not ALWAYS updated", unless you specify > a specific system. This machine obviously updates access time upon execution: > Gurus: Which systems DO update access time upon execution (presuming it's > possible at all, e.g., not on a readonly filesystem)? Which systems don't? Of the systems I'm currently using: USG 2.0v2p on vax-780 does NOT Unix PC (hybrid) 3.5 does BSD 4.2 on Sun 3/60 does USG 5.2.5 on Amdahl does NOT if the sticky bit is set; does otherwise. Updating st_atime on exec is NOT required by SVID (Issue 2; Vol.1, p. 127). Adam Reed (mtgzz!avr)
phil@osiris.UUCP (05/13/88)
Pyramid OSx (a BSD/SysV dual-port UNIX) also updates the access time when
a file is executed. This seems to be pretty generic behavior, perhaps
the original poster really did miss something fundamental...
Phil Kos
Information Systems
...!uunet!pyrdc!osiris!phil The Johns Hopkins Hospital
Baltimore, MD