stealth technology for find(1)
Jeff Carter
jeffc at soba.osf.org
Tue Aug 8 23:50:25 AEST 1989
In article <3584 at mentor.cc.purdue.edu> dls at 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
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list