[comp.os.vms] Uses for access time

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.edu

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

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