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