🚀 go-pugleaf

In article <3584@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L. Stevens) writes:
>Index:	/usr/src/usr.bin/find/find.c 4.3BSD
>
>Description:
>	find(1) changes atimes for all directories it searches, which makes
>the "-atime" predicate less useful. The find(1) itself changes the directory
>access times so they never age.
>
>Repeat-By:
>	find / -atime ...
>
>Fix:
>	Save the utimes for directories before reading them and restore them
>on the way back up.  (Works for root or directory owners, only) Diffs follow:

Are you sure this is really 
(A) a bug?
(B) a fix?

Consulting my 4.3BSD manual, for stat(2):
  st_atime: Time when _file_ _data_ was last read or modified. Changed by the 
	following system calls: mknod(2), utimes(2), read(2), and write(2).
	For reasons of efficiency, st_atime is _not_ set when a directory is
	searched, although this would be more logical. [emphasis mine]

And running a quickie experiment on ULTRIX 3.0: (a berkeley derivative)
  % date
  Tue Aug  8 09:39:44 EDT 1989
  % ls -ldg TRC
  drwxr-x---  6 jeffc    osf           512 Apr 25 11:15 TRC/	[modify time]
  % ls -ldug TRC
  drwxr-x---  6 jeffc    osf           512 Mar 11 14:15 TRC/	[access time]
  % find ./TRC -print
  [much output deleted]
  % ls -ldg TRC
  drwxr-x---  6 jeffc    osf           512 Apr 25 11:15 TRC/	[modify time]
  % ls -ldgu TRC
  drwxr-x---  6 jeffc    osf           512 Mar 11 14:15 TRC/	[access time]
  % find ./TRC -atime -2 -print
  [no output. i.e., no file/directory under ./TRC accessed in less than 2 days]
Access time did not change.

Additionally, the "fix" has the following effect:
4.3BSD utimes(2):
  The utimes call uses the "accessed" and "updated" [ should be "modified" ]
  times in that order from the tvp vector to set the corresponding recorded 
  times for _file_.

  The caller must be the owner of the file or the super-user. The 
  "inode-changed" time of the the file is set to the current time.

The effect of this is to change st_ctime on every directory that you do this
to. Why is this bad? (OK, suboptimal) because dump(8) uses st_ctime as 
one of the criteria for whether or not an inode should be dumped. This will
make dump run slower and take more tape. There may be other side-effects
that I am not aware of.

Jeff Carter