Locking a file while copying using Commons IO

Question

I am using the Apache Commons IO:

     FileUtils.copyFileToDirectory(srcFile, destDir)

How do I make Windows lock the destination file during copy? Windows locks the file correctly if I use:

      Runtime.getRuntime().exec(
      "cmd /c copy /Y \"" + srcFile.getCanonicalPath() + "\" \""
          + destDir.getCanonicalPath() + "\"").waitFor();

Notes: The contention is not with the local program, but an external one. The file is being copied to a remote system. The remote system is processing the file before it completes the copy. Because the systems are Windows, the normal copy locks the file and blocks the external program from access.

Answer 1

Java doesn't natively support file locking.

If contention for the file is coming from within your program, perhaps you need to build additional synchronization on top of the file copy to make sure concurrent writes don't clobber one another. However, if the contention is coming from somewhere external to your software then there isn't much you can do. You can try writing the file to a temporary directory and then renaming it since the rename is more or less atomic (depending on the filesystem).

It would help to have more information on why you need to lock the file in the first place.

The contention is not with the local program, but an external one. The file is being copied to a remote system. The remote system is processing the file before it completes the copy. Because the systems are Windows, the normal copy locks the file and blocks the external program from access.

In that case, you should try writing to a temporary file and then renaming it when the file is fully copied. File renames are atomic operations (on a non networked filesystem) so it should work for you.

Answer 2

When copying files, always copy to a temporary filename and rename the file when you are done writing. This way, another process can never see a corrupt file.

Even better, you can write to *.tmp. Then check if the destination file exists. Rename the dest file to *.bak if it exists. Lastly rename *.tmp -> dest.

Answer 3

java.nio.channels.FileChannel will allow you to acquire a FileLock on a file, using a method native to the underlying file system, assuming such functionality is supported.

This lock operates across processes on the machine, even non-java ones. (In fact, the lock is held on behalf of the specific JVM instance, so is not suitable for managing contention between multiple threads in a process, or multiple processes in the same JVM).

There are lots of caveats here, but it is worth investigating if you are working on Windows.

From the javadoc:

This file-locking API is intended to map directly to the native locking facility of the underlying operating system. Thus the locks held on a file should be visible to all programs that have access to the file, regardless of the language in which those programs are written.

Whether or not a lock actually prevents another program from accessing the content of the locked region is system-dependent and therefore unspecified. The native file-locking facilities of some systems are merely advisory, meaning that programs must cooperatively observe a known locking protocol in order to guarantee data integrity. On other systems native file locks are mandatory, meaning that if one program locks a region of a file then other programs are actually prevented from accessing that region in a way that would violate the lock. On yet other systems, whether native file locks are advisory or mandatory is configurable on a per-file basis. To ensure consistent and correct behavior across platforms, it is strongly recommended that the locks provided by this API be used as if they were advisory locks.

On some systems, acquiring a mandatory lock on a region of a file prevents that region from being mapped into memory, and vice versa. Programs that combine locking and mapping should be prepared for this combination to fail.

On some systems, closing a channel releases all locks held by the Java virtual machine on the underlying file regardless of whether the locks were acquired via that channel or via another channel open on the same file. It is strongly recommended that, within a program, a unique channel be used to acquire all locks on any given file.

Some network filesystems permit file locking to be used with memory-mapped files only when the locked regions are page-aligned and a whole multiple of the underlying hardware's page size. Some network filesystems do not implement file locks on regions that extend past a certain position, often 230 or 231. In general, great care should be taken when locking files that reside on network filesystems.`