Tutorial on find(1) -mtime: a Better Way.

[Tony Olekshy]

TUTORIAL OHA/BXX/NNMF: Finding Files Relative to A TimeStamp.

As regards the use of the -mtime option to find(1) files, for example those
that have recently changed, -mtime computes 1 day == 24 hours, and as has been
pointed out find uses integer division such that 4 days minus epsilon is *not*
greater than 3 days!

The whole problem here is that the granularity of the -mtime computation is
usually not suitable for problems that depend on one day precision.  For
example, find /tmp -mtime +6 is *ok* for weekly removal of old /tmp files.
It obviously won't work for "get me a list of files that have arrived since
the news transmission that started at 6:15 this morning".

Now, the way to move the granularity of the comparison to 1 minute precision
is to create a dummy file, set its modification time using the touch(1)
command, and use the -newer (or ! -newer) option of find(1).  Using the Xenix
touch(C) command I can

		touch -m mmddhhmm[yy] /tmp/stamp.$$
		find ... -newer /tmp/stamp.$$ ...
		rm /tmp/stamp.$$

Also note that if you need 1 second precision and your touch(1) command can't
set the modification time to the second, you can use a little c program to
call utime(3).  In fact, take one of the date calculators posted to the
various source groups and add an option to utime() a file with the result of
the date calculation, so you can say

		calcdate -t /tmp/stamp.$$ now - 1 day

Note that there is an additional advantage here.  I would not be surprised
if two models of UNIX (TM AT&T ;-) handled find's -mtime differently, but
I would be surprised if -newer didn't work the same on all systems.  (This
paragraph has been duly registered as anti-flame insurance.)

Slightly tangentially (is that a word?), if you are using a file as a
timestamp for -newer to generate incremental backups of files changed since
the last backup, be sure to use this technique:

		touch stamp.new
		find ... -newer stamp.old ...
		mv stamp.new stamp.old

You may get a file on two consecutive media-sets if it changes during the
backup (although you should go to some length to prevent files from changing
during a backup), but at least you won't get a file that isn't backed up even
though it changed.

Finally, if you are going do this manually and often, wrap the touch/find
commands in a shell script that uses the trap builtin to remove /tmp/stamp.$$
when the script exits, and presto, you have created a new and useful command
that you will probably forget the name of in a day or two!

Yours, etc., Tony Olekshy (...!alberta!oha!tony or tony at oha.UUCP).