From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Description of problem:
Steps to Reproduce:
1.Have an application that creates a file in /tmp but keeps it open
2.wait 10 days
Actual Results: File deleted
Expected Results: File should not of been deleted
tmpwatch does not need to use the fuser command, there are API calls to
determine if a file is open ...
there are no API calls that I know of to determine if a file is open. The only
(non-portable) way I know of is to look in /proc/<process-id>/fd/<ids>, which is
basically what fuser does. It walks this list and gives you the results. Problem with
checking this is that it is racey; any program could open a file after you have already
checked that PID and then you wouldn't know it because you have already examined
the FDs for that PID.
Second, it is semantically OK if you remove (unlink) a file if another already has it open.
The data will still be written correctly. When the process quits, the data will go away. If
some program is writing to a file in /tmp less than once every 10 days or so, chances
are very high that it will not care if tmpwatch unlinks it.