Skip to content

Prevent and Detect Deletion of an Open File

My Java program opens a file and slowly writes to the file. When the operation is completed, the program closes the file and moves the file to its final resting place in another directory. The problem is that as the operation is running, another thread in the same Java program deletes the file.

Windows will not allow the deletion of a file while it is open. Linux allows the file to be deleted while open. On NFS file systems, Linux will rename the file and then automatically delete the file when it is closed. How do I prevent the deletion of files while they are open?

How do I figure out what is deleting the file? How do I get the call stack of the Java thread in my program that is deleting the file?

Changing the file owner will not work since another thread in the same process is deleting the file.

The program is actively writing to the file so removing the write permission on the file will not work. Removing the write permission on the directory will not work either since the directory has other files being created and deleted.

The program has 185k lines of code. There are many calls to File.delete() throughout the code. I could set a breakpoint on File.delete(), Files.delete(), etc. However, the program is creating and deleting a lot of files quickly. This will generate a lot of breakpoint hits burying the needle in the haystack. I could make the breakpoint conditional but then the program will run very slowly.


The JDK’s file locking mechanism only protects the file from other processes and not threads from the same process.

So, I wrote a read/write file locking framework. If any thread is holding a read or write lock on a file, then all other threads cannot write or delete the file. If a thread is holding a read lock on a file, then it can’t write or delete the file. While a thread has a read or write lock on a file, none of the ancestor directories can be deleted.

This framework flushed out the bugs very quickly. I have not seen a problem since.