Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!zephyr.ens.tek.com!tekcrl!tekfdi!videovax!bart
From: bart@videovax.tv.Tek.com (Bart Massey)
Newsgroups: comp.bugs.4bsd
Subject: Re: stealth technology for find(1)
Message-ID: <5521@videovax.tv.Tek.com>
Date: 9 Aug 89 22:50:55 GMT
References: <3584@mentor.cc.purdue.edu> <250@paperboy.OSF.ORG> <3588@mentor.cc.purdue.edu> <3608@mentor.cc.purdue.edu>
Reply-To: bart@videovax.tv.tek.com (Bart Massey)
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 30

In article <3608@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
> 
> 	The "local changes" that caused find(1) to suddenly start changing
> the atimes on directories were in fact the Tahoe changes and not something
> we did. It was in fact the 4.3 version, not the Tahoe version, that I tested
> and that did not have the problem.

We're running 4.3 "tahoe" on a VAX750, and our man page still says

     st_atime    Time when file data was last accessed.  Changed
                 by the following system calls: mknod(2),
                 utimes(2), and read(2).  For reasons of effi-
                 ciency, st_atime is not set when a directory is
                 searched, although this would be more logical.

An experiment convinced me that either the manpage or the kernel is wrong.
As the manpage says, it was mainly an efficiency win to not do this before,
so maybe the kernel behavior was deliberately changed and not documented.
Or maybe it's a kernel bug.  Could somebody at Berkeley clarify this?

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart