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.eduraveling@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
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!"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)
mike@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
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (05/07/88)
> Yes. These are reasons enough. Security (knowing whether a file has > been modified, and when) is a singular "reason enough!" One of the other > important reasons for recording last-access time (most especially > last-modified time) is for backup purposes. Performing an incremental > backup would be difficult without knowing which files had changed at what > times. An operating system ~could~ just maintain a one-bit flag for each > file indicating 'file-modified', and reset the bit each time the file was > backed-up. But this austere method eliminates security tracking and > precludes any flexibilty on selective backups (by date/time) {in the words > of Yul Bryner: etc, etc, etc...} I'm afraid that Brian Hagerty is missing the point. The question was about last access time, as distinct from last modification time. There are, as he states, very good reasons for maintaining a last modification time. Last access time is less clearly useful unless you're running in a pretty secure environment and need to know if someone has seen something he shouldn't. The main use I've seen for maintaining a last-access time for a file is for archiving purposes: if nobody's used a file for a long time, you might want to move it to tape. If you've got only a few sensitive files, you can put alarm acl's on them. For archiving purposes, you don't need to keep close track of the last access time; you need a resolution equal to how long it can be since a file has been accessed before you want to archive it. This can be done by setting the retention period on the volume (on CITHEX, this is 6 months minimum, 6 months and a day maximum).
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