Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!gymble!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: file read dates
Message-ID: <2952@umcp-cs.UUCP>
Date: Thu, 30-Jan-86 14:18:09 EST
Article-I.D.: umcp-cs.2952
Posted: Thu Jan 30 14:18:09 1986
Date-Received: Sat, 1-Feb-86 05:53:13 EST
References: <183@magic.ARPA>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 33

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