From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT) Description of problem: How reproducible: Always 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 Additional info: 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.