java - 为什么 Java 的 `.dateLastModified` 在某些 Windows 7 文件中会被截断？

Question

我正在编写一个备份程序，因为 Windows 由于某种原因拒绝让我使用它的备份程序。 (我收到一个错误代码，如果需要，我可以报告该错误代码。)

我只想复制比同名目标节点文件新的源节点文件。

我发现，尽管 Windows 属性 中两个文件的最后修改日期显示为相同，但源几乎总是被复制 - 即使它不是较新的。

以下是声明:

File from_file = new File(from_name);
File to_file   = new File(to_name)

这是我最终在不同文件夹中找到的两个同名文件。

即使文件的“属性”窗口中显示日期，.lastModified() 返回的最后 3 位数字对于一个文件可能不为零，而对于另一个文件则为零看起来相同。

我的问题是为什么会这样？？？

经过多次挫折和调试，我有一个解决方法:

 destinationIsOlder = ((long)(from_file.lastModified()/1000)*1000 
                       > 
                       (long)(  to_file.lastModified()/1000)*1000);

但是为什么我必须这样做呢？即，Windows 在做什么？应该这样做吗？这是一个错误吗？

还有什么类似的邪恶在等待着我？

也就是说，我应该除以大于 1000 的整数吗？

(复制一个在技术上错误地报告为较新几毫秒的文件并不是世界末日，但如果源文件夹中的每个文件都发生这种情况，那么会对驱动器造成很大的磨损子文件夹!)

(我可能只是偶然发现为什么 xcopy 也没有执行我想要的操作。)

编辑上面显示的两个调用返回的时间是

1419714384951 来自 from_file.lastModified() 和

1419714384000 来自 to_file.lastModified()。因此，虽然相同(包括显示的日期和时间)，但 from_file 较新，因此，按照规则，复制，但不恰当。

Answer 1

lastModified 返回一个毫秒精度的 long - 因此最后 3 位数字代表秒的一小部分。

由于文件属性对话框仅显示最多秒的时间，因此两个文件将显示相同的值。

为什么有些是零，有些是非零？有很多原因。如果文件是从其他地方复制的，只有第二精度，则它将为零。如果应用程序显式更改文件修改时间，它可能只会使用第二个分辨率来执行此操作。等等。

最后，我认为它不会对您的备份方案产生太大影响，让您不必担心。