Path: utzoo!utgpu!watmath!iuvax!purdue!mentor.cc.purdue.edu!dls
From: dls@mentor.cc.purdue.edu (David L Stevens)
Newsgroups: comp.bugs.4bsd
Subject: Re: stealth technology for find(1)
Keywords: atimes, utimes(2), find(1)
Message-ID: <3608@mentor.cc.purdue.edu>
Date: 8 Aug 89 22:29:34 GMT
References: <3584@mentor.cc.purdue.edu> <250@paperboy.OSF.ORG> <3588@mentor.cc.purdue.edu>
Organization: PUCC UNIX Group
Lines: 41


	For what it's worth, I have further information and I'm removing
my foot from my mouth and replacing it for the premature retraction....

	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.
	The STEALTH code avoids that and allows, for example, /tmp to be
cleared based on access times, without leaving a tree of empty directories
for some other cleanup method. Some have suggested that it be a command line
option.
	I don't have a good feel for the dump/ctime argument; all of the
directories generally aren't much compared to all of the files, anyway. At
any rate, the code is there for you to use or not. :-)

	Another find(1) question that we're addressing locally is the
unintuitive meaning of numbers in the comparisons. As it is, there are
three forms ("n", "+n" and "-n"). However, fractions are completely truncated
so to match a "-mtime +1" requires a file to actually be *two* days or older.
A file that's anywhere from 1 day and 1 second to 1 day, twenty three hours
59 minutes and 59 seconds old are all considered to be one day old and fail
the "greater than a day" test.
	I propose:

	1) To match "+n", a file need be n days + 1 second or older.
		(current: n days + 24 hours)
	2) to match "-n", a file need be n days - 1 second or younger.
		(current: same)
	3) to match "n", a file should be +/- a reasonable epsilon.
		(current: n+1 sec to n+23 hours 59 mins 59 secs)
		I suggest an hour, so files 23.00.01-25.00.59 would be
		considered an "exact" day-old match, but a file that's
		1 day, 22 hours old would not. Could also use epsilon in
		1) and 2) to maintain a dichotomy.

	The most obtuse example is a file that's 1 second short of two days
old and won't match on "+1", even though the file is in fact 1.99998 days old.
Most people'd call that 2, but anyone'd call it >1.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)