The documentation for File.createNewFile say "This method, in combination with the deleteOnExit() method, can therefore serve as the basis for a simple but reliable cooperative file-locking protocol."  This statement is false and dangerously misguided.

If you mark the file as deleteOnExit *before* invoking createNewFile but the file already exists, you run the risk of deleting a file you didn't create and dropping someone elses lock!  On the other hand, if you mark the file *after* creating it, you lose atomicity: if the program exits before the file is marked, it won't get deleted and the lock will be "wedged".

Luckily, a proper file-locking facility was added in release 1.4 (java.nio.channels Class FileLock).  The disinformative notation on File.createNewFile should be replaced by something like this:

"Note: this method should <i>not</i> be used for file-locking, as the resulting protocol cannot be made to work reliably.  The {@link java.nio.channels.FileLock FileLock} facility should be used instead."

Perhaps this note should be added to the doc comment for File.deleteOnExit as well.

N/A

Simple fix. Will add note to both methods as mentioned in the bug report.

  xxxxx@xxxxx   2002-05-06

I don't think this is totally accurate.  The problem here is
with using deleteOnExit for the file locking protocol and
not createNewFile.  A simple file locking protocol where one
process creates a lock file with createNewFile, writes a
timestamp into the file, and periodically updates that time
stamp to show that the lock hasn't gone stale should work
just fine.

Other processes can than periodically try to create their
own lock file, and if they fail, then they can look at the
time stamp.  If the time stamp is stale, then can delete the
file and try to atomically create the file again.  Wash,
rinse, repeat.

The only problem with this method is the latency around how
long it takes to clean up a lock after a controlling process
has crashed.