Shell Programming and Scripting

Hi

I run the below command to find and delete *.xml files 90 or more days old.

Code:

find . -type f -name '*.xml' -mtime +90 -exec rm {} \;
find: stat() error ./Hello/2014_EMPTY.xml: No such file or directory
./Hello/2014_EMPTY_8011.xml: No such file or directory
.....
....

If the file does not exists why is the my find even finding it and trying to delete something that does not exist?

Is it caching the find results causing this problem ?

I was not seeing this behaviour. Any guesses on how can i get my command working ?

I am on Unix Sparc.

First off, add echo before rm. Never ever ever run a batch deletion script you haven't tested.

This is suppose to run as a crontab.

I had use this command with rm -i option and it all looked good in the first run.

Could be my crontab tab is running in the background and its is deleting the files and when i run it manually it does not find the file .. .thats my wild guess. But how can i confirm ?

ps -ef | grep purge.sh
does not yield any results where purge.sh has that find and remove command i post in the OP; to show that the BG process is running or maybe there is a problem with the ps command

Not sure what has happened now ?

An error message like that usually means that another process removed that file while find was walking the file hierarchy. In other words:

Say if another process as part of the crontab is running in the background that is deleting the file ... how can i find it's pid ?

The disk space usuage is reducing indicating that there must be a process running in the bg as part of the crontab.

Both the below commands do not yield any results.

Code:

bash-3.2$ /usr/ucb/ps -auxwww | grep purge*
bash-3.2$ /usr/ucb/ps -auxwww | grep find*

How can i stop the process ?

Nothing says that the other process that removed, moved, or deleted that file was being run by another find command nor that it had been started by cron. Anybody logged on to your network with write access to the directory in question could remove a file. And, by the time you see the error message, that process could already be gone. There might not be a running process left to find. If you have process accounting running, you might be able to find who was running another process at the time find reported the error.

Of course if you were running the two copies of the same script at the same time, you could easily see several errors like that as they fight with each other trying to be the first one to find and process the selected files. But, if you have only seen this once, it is more likely that someone manually removed a file while your cron job was running.

I hate find I've found it be to FAIL so many more times than successful.

You'd see better speed (and shorter arguments) ls -1'ing to a temp file, grep'ing the tmp, then cleaning up.

Find is THAT slow and shi**y.