UNIX for Dummies Questions & Answers

I've got a job that finds and removes trace files based upon an access time of more than seven days (I've also tried a modify date).

Code:

find TABC*[0-9][0-9] -atime +7 -exec rm +

Code:

find TABC*[0-9][0-9] -mtime +7 -exec rm +

Whether I use -atime or -mtime, the process seems to work sporadically. Sometimes it removes the files as expected. Other times it won't "find" them at all. These files contain lots of data that I frequently grep/awk/head/tail through, so I am wondering if any of those commands would update my file's access date/time values, and thus render my find inaccurate.

Thank you!

Yes, they would affect the access time, but not the modification time.

Code:

$ ls -lu file
-rw-r--r--  1 scott  staff  157 14 Jun 17:37 file
$ grep x file
$ ls -lu file
-rw-r--r--  1 scott  staff  157 14 Jun 19:03 file

Duplicate info deleted.

----------------

Based on Scott's following comment, I have restored the original content of this message:

As long as you aren't using some mount option that skips timestamp updates, any successful attempt to read data from a file will mark the access timestamp for that file for update. Sometime between when that timestamp is marked for update and the next time you successfully stat() the file, the access timestamp will be set to the current time.

Find will stat() every filename in the current directory that matches the filename matching pattern TABC*[0-9][0-9] and, if any of those filenames name a directory, any files in those directories recursively). All of the commands you specified (awk, grep, head, and tail) will attempt to read a file (and if successful, will mark the access timestamp for those files for update).
PS
Your find statement is missing an operand for rm. You probably meant:

Code:

find TABC*[0-9][0-9] -mtime +7 -exec rm {} +

Of course, I hadn't considered mount options like "noatime". A very clear explanation, Don.

I like to use "| xargs -n101" rather than "-exec {} +" as you get some pipeline parallelism: find does not stop while it is running rm.

You also have to consider that a regular backup of the files will access them.

I have some replication software on a server and after the schedule, there is a pause waiting for some large outgoing file transfers and then the backup kicks in. On the data transmission logs for the replication software, we can see a vast I/O increase when the back is reading several million small files, and this information is replicated to the remote site.

Sorry if I'm the bearer of bad news.




Robin
Liverpool/Blackburn
UK

Yes, it is less durable than the archive bit in Windows, and so of little use. Most practical apps use the date modified, to control backup and archiving. For casual use, "find -mtime -<days>" is good, but for precise set definition you need something like:

Code:

touch marker_new
sleep 1 # get out of new marker file's second
find ... -newer marker_last ! -newer marker_new | ...
mv -f marker_last marker_done # in case you need a rerun
mv marker_new marker_last

---------- Post updated at 12:19 PM ---------- Previous update was at 12:15 PM ----------

Yes, it is less durable than the archive bit in Windows, and so of little use. Most practical apps use the date modified, to control backup and archiving. For casual use, "find -mtime -<days>" is good, but for precise set definition you need something like:

Code:

touch marker_new
sleep 1 # get out of new marker file's second
find ... -newer marker_last ! -newer marker_new | ...
mv -f marker_last marker_done # in case you need a rerun
mv marker_new marker_last

You need to bracket your files with two dates in the past. If you start in th current second, you might miss files modified later in that second. A second is a long time for a modern computer !