find found files that don't exist?
 

Hi,

I was using the following command to search for tmp files older than 15 days for deletion

I used "ls -l" first just in case
then i noticed that occasionally i get a "No such file or directory" error

When I looked at the directory, the file was not there.

How does "find" find a file that doesn't exist?

Is it possible that the file can be deleted right at the moment after a file is found and before the command executed?

The short answer is yes. (Especially in /tmp.)

Re: find found files that don't exist?
 

Yes, and what is stranger yet is that these files can also take up space on your filesystem!!! No this is not a bug!!! The size of theses files may not be trivial either. My first exposure to this phenomenon came when I noticed and tried to determine why one of the web servers I was developing on had 1.2 GB discrepancy between the output listings of "df -h" and "du -h". No, this is not a bug!!! To find the files in question, look at the output of "lsof -D /somedirectory" and you should see the files referenced by "ls" as could not be found. To further explain what is happening with the command line "find somedirectory/ -type f -ctime +15 -exec ls -l {} \;", which it seems the OP does understand but just for clarification. The "find" command is searching the directory "somedirectory/" for file "-type f" created more than fifteen days ago "-ctime +15" and execute a directory listing with the command "ls -l" to files found from the find command. So as the questions' asker determined, this is a strange occurrence, why would the "find" command find files that "ls" could not list. To better explain this we need to understand how linux filesystems (ext2, ext3 and many others) store information on disc and how the linux kernel handles the deletion of a file that is opened by another program or process. The second part of the last statement indicates when this happens (Perhaps there are others? If anybody finds what I am saying to be incomplete or needing correction please let me know as I and not a kernel developer.), that is when a file is deleted while another program has that file open. A classic example of this is a log file, and this was the case for me as well. So a log file is deleted, either manually, using logrotate or other means but the log file is still opened and being written to by the application. How does the operating system handle this? First we need to understand that when a file is saved to disc that there are effectively two entries in the file system for the file one for the file itself and other called an inode table entry which tells the operating system crucial information about the file (size, location etc.). When a file is opened for writing by the an application the operating system reads a copy of the file into memory for modification and puts a lock on the inode table entry until the file is saved, at which time both the file and the inode entry are updated. So now lets take the case where a file is opened for writing and during which time the file is deleted from the filesystem hierarchy. As before, the operating system copies the file into memory for modification and locks the inode entry. The file gets deleted, but the inode entry for that file still remains and will continue too until the process that has the file opened terminates. To find out why, ls does not show these files even though the inode entry still exists, I had to look a the the ls source code. The ls command does use the inode table to list files, directories etc., but performs a check opendir() before listing the file to ensure that it exists. Otherwise it will display the familiar "No such file or directory" message.

go_tux_yourself

I think 'ls' is redundant here, why are you using it ?

EDIT:

For example you could instead do:

Or see the '-printf' option.