java.nio.Files.move() - DirectoryNotEmptyException

2019-08-10 22:02发布

问题:

I'm running a 3rd party library, and part of its operation is to download a zip file to a temp directory, unzip it and then move it from the temp directory to a final directory... for some reason, this fails when I leave system properties to the default:

java.nio.file.DirectoryNotEmptyException: /var/folders/j_/1v53z7q15v51wyb00jzht_ch0000gn/T/vertx-68e24a9e-ee15-4b49-a796-7176714865ec
   at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:491)
   at sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:261)
   at java.nio.file.Files.move(Files.java:1345)
   ...

However if I set java.io.tmpdir to .tmp (and create a .tmp directory in my working dir), it works!

This also does not work if I use sudo.

This is really pissing me off... what do I need to do to get this working on OS X?

> java -version
  java version "1.7.0_17"
  Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
  Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

> uname -a
  Darwin daryl-teos-macbook-pro.fritz.box 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64

Regards, Daryl

回答1:

Given the following from the Java API Docs for Files.move:

When invoked to move a directory that is not empty then the directory is moved if it does not require moving the entries in the directory. For example, renaming a directory on the same FileStore will usually not require moving the entries in the directory. When moving a directory requires that its entries be moved then this method fails (by throwing an IOException). To move a file tree may involve copying rather than moving directories and this can be done using the copy method in conjunction with the Files.walkFileTree utility method.

This implies that this function was not designed to move files across networks or different FileStores. It works for you when you change the tmp location because in that case it is simply doing a rename and not a physical move.

You did not mention how the 'final directory' is selected but if it is user controlled it seems as if it would have to be a local location.