如何确定文件是否将被逻辑移动或物理移动 [英] How to determine if a file will be logically moved or physically moved

问题描述

事实：

移动文件时，有两种可能：

源文件和目标文件在同一个分区上，只有文件系统索引被更新。

源文件和目标文件位于两个不同的文件系统上该文件需要被移动每个字节的字节。 （aka copy on move）

问题：
$ b $我怎样才能确定一个文件将是逻辑或物理移动？

我正在传输大文件（700 + megs），并会采取一个不同的
$ b $ hr

编辑：

I'我已经编写了一个移动的文件对话框与一个工作线程执行阻止IO调用一次复制一个兆字节的文件。它向用户提供信息，如粗略估计剩余时间和传输速率。

问题是：如何才能知道文件是否可以在物理上移动之前进行逻辑移动？

$ b

解决方案

确定我在做什么： 使用 JNA 我可以调用Win32 API （和* nix API我也试过调用 GetFileInformationByHandle 并得到了一个结果BUT dwVolumeSerialNumber 属性总是等于0（尝试用我的C：和D：驱动器）

然后我看到这个函数在MSDN上： MoveFileEx 。标志参数设置为0时，复制移动功能将被禁用。因此，我只是简单地称之为

<$ p $

如果（！Kernel32.INSTANCE.MoveFileEx（source.getAbsolutePath（），destination.getAbsolutePath（），0））{
System.out.println（逻辑移动失败）;



$ b

这里是放入 Kernel32的代码。 java 接口（这个文件可以在 JNA 网站）：

 布尔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; 
  

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 ?

解决方案

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;

这篇关于如何确定文件是否将被逻辑移动或物理移动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！