Question

The facts:

When a file is moved, there’s two possibilities:

1. The source and destination file are on the same partition and only the file system index is updated
2. The source and destination are on two different file system and the file need to be moved byte per byte. (aka copy on move)

The question:

How can I determine if a file will be either logically or physically moved ?

I’m transferring large files (700+ megs) and would adopt a different behaviors for each situation.

---

Edit:

I’ve already coded a moving file dialog with a worker thread that perform the blocking io call to copy the file a meg at a time. It provide information to the user like rough estimate of the remaining time and transfer rate.

The problem is: how do I know if the file can be moved logically before trying to move it physically ?

Answer 1

Ok I’m on something 🙂

Using JNA I am able to call the Win32 API (and *nix API too) from java.

I tried calling GetFileInformationByHandle and did got a result BUT the dwVolumeSerialNumber attribute always equals 0 (tried with my C: and D: drive)

Then I saw this function on MSDN: MoveFileEx. When the flag parametter is set to 0, the copy on move feature will be disable. AND IT WORKS !!!!

So I will simply call

if (!Kernel32.INSTANCE.MoveFileEx(source.getAbsolutePath(), destination.getAbsolutePath(), 0)) {
    System.out.println("logical move failed");
}

Here is the code to put in the Kernel32.java interface (this file can be found in the src.zip package in the download section of the JNA site):

boolean MoveFileEx(String lpExistingFileName, String lpNewFileName, int dwFlags);

int MOVEFILE_REPLACE_EXISTING = 0x01;
int MOVEFILE_COPY_ALLOWED = 0x02;
int MOVEFILE_CREATE_HARDLINK = 0x04;
int MOVEFILE_WRITE_THROUGH = 0x08;
int MOVEFILE_DELAY_UNTIL_REBOOT = 0x10;
int MOVEFILE_FAIL_IF_NOT_TRACKABLE = 0x20;