Wrong exception thrown?

[John Hendrikx]

> John Hendrikx wrote:
>> Exception in  thread "Thread-8": java.nio.file.AccessDeniedException:
>> c:\Copy\Macros2 -> c:\Copy2\Macros2
>> 	at
>> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
>> 	at
>> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
>> 	at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
>> 	at sun.nio.fs.WindowsPath.implMoveTo(WindowsPath.java:1004)
>> 	at sun.nio.fs.AbstractPath.moveTo(AbstractPath.java:201)
>> 	at
>> hs.filemanager.transfer.RenameFileVisitor.rename(RenameFileVisitor.java:67)
>>
>> This occurs when moveTo() is called with the arguments indicated +
>> ATOMIC_MOVE.
>>
>> I would expect the FileAlreadyExistsException to be thrown.  It's not a
>> permission issue (and the files are not 'read only').
>>
>>
> When the ATOMIC_MOVE option is specified then it is allowed to replace
> the target file if it exists. In other words, it is not required to fail
> if the target exists. An implementation can't first check if the file
> exists because the overall operation must be atomic. One annoyance, as
> Andrew suspected,  is that Windows returns its equivalent of "access
> denied" for both the permission denied case and the case that the target
> is a directory. Is C:\Copy2\Macros2 is a directory?

Yes, correct it was a directory.

I didn't however specify REPLACE_EXISTING, only ATOMIC_MOVE (and the
latter is documented to "ignore all other options").

I'm actually only trying to accomplish a simple rename of the directory --
but I couldn't find any other function that accomplishes this in nio2, so
I suspected that srcPath.moveTo(dstPath, ATOMIC_MOVE) is the closest thing
to it.  I must specify ATOMIC_MOVE to prevent it actually moving any data,
only a rename is desired.

Would it be better to instead check if srcPath and dstPath are on the same
FileStore and only then call srcPath.moveTo(dstPath) without any further
arguments?

Best regards,
John Hendrikx