FileBot

Posted: **12 Feb 2014, 14:09**

Hi,

I have struggled with moving files to another drive during renaming on Windows (e.g. from D:\Somefile.mkv to E:\RenamedFile.mkv). Everytime it would fail with an AtomicMoveNotSupportedException.

After browsing through the latest code from SVN I realized, that FileBot should use copy+delete operation from apache commons when the standard move fails. However, it only catches LinkageException in these cases:

File: source/net/sourceforge/tuned/FileUtilities.java (ll. 54 - 60)

Code: Select all

// move file
try {
	// * On Windows ATOMIC_MOVE allows us to rename files even if only lower/upper-case changes (without ATOMIC_MOVE the operation would be ignored)
	java.nio.file.Files.move(source.toPath(), destination.toPath(), StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);
} catch (LinkageError e) {
	org.apache.commons.io.FileUtils.moveFile(source, destination); // use "copy and delete" as fallback if standard rename fails
}

I corrected the error by also catching AtomicMoveNotSupportedException:
File: source/net/sourceforge/tuned/FileUtilities.java (ll. 54 - 60)

Code: Select all

// move file
try {
	// * On Windows ATOMIC_MOVE allows us to rename files even if only lower/upper-case changes (without ATOMIC_MOVE the operation would be ignored)
	java.nio.file.Files.move(source.toPath(), destination.toPath(), StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);
} catch (LinkageError | AtomicMoveNotSupportedException e) {
	org.apache.commons.io.FileUtils.moveFile(source, destination); // use "copy and delete" as fallback if standard rename fails
}

This change also required to change target and source in the ant build script from 1.6 to 1.7.

It'd be great if you could incorporate this fix, because I'm sure not the only one who wants to move files between drives in Windows

Posted: **12 Feb 2014, 15:56**

LinkageException is caught specifically to have it default to Commons IO on Java 6 where Java 7 functions are not available.

ATOMIC_MOVE flag is required to change the case when renaming Windows-identical files. Any idea why ATOMIC_MOVE may not be supported in your case?

Posted: **12 Feb 2014, 23:53**

I am running Java 7. The exception is thrown because Java can't move the file to another drive in a single atomic move. According to http://docs.oracle.com/javase/7/docs/ap ... .html#move(java.nio.file.Path, java.nio.file.Path, java.nio.file.CopyOption...) Java actually performs a copy+delete when the target is on another filesystem, making the move transaction consist of two separate operations.

However, when using the GUI it works perfectly. I didn't look into it, but maybe it's because the GUI uses a different implementation of RenameAction than StandardRenameAction (e.g. NativeRenameAction)?

The multi catch in my ad hoc fix is just for convenience. To retain Java 6 compatibility it'd suffice to catch the exception in a separate catch block, although this may produce duplicate code for calling the fallback.

Posted: **13 Feb 2014, 09:35**

Yep. I'll make a fallback without the atomic flag then.

EDIT: Fixed with r2037

FileBot

[Error] AtomicMoveNotSupportedException on Windows

[Error] AtomicMoveNotSupportedException on Windows

Re: [Error] AtomicMoveNotSupportedException on Windows

Re: [Error] AtomicMoveNotSupportedException on Windows

Re: [Error] AtomicMoveNotSupportedException on Windows