Files#delete(Path) 和 File#delete() 之间的区别答案

【问题标题】：Difference between Files#delete(Path) and File#delete()Files#delete(Path) 和 File#delete() 之间的区别
【发布时间】：2012-08-21 19:02:46
【问题描述】：

我正在使用带有 java 7 update 6 的 Windows-7，发现这种奇怪的（至少对我而言）行为 -
我有两个文件 E:\delete1.txt 和 E:\delete2.txt 都是只读文件，当我尝试删除文件时，如下所示，它被删除而没有任何问题 -

File file = new File("E:\\delete1.txt"); 
assertTrue(file.delete());

但是当我使用如下的 nio API 删除文件时 -

Path path = Paths.get("E:\\delete2.txt");
Files.delete(path);

它抛出java.nio.file.AccessDeniedException。

为什么新旧 nio API 的相同操作会有不同的行为？

【问题讨论】：

如果你交换你正在删除的文件，即NIO api 删除delete1.txt 和旧的 api File 删除delete2.txt 会发生什么？
@MichaelBorgwardt 为什么很奇怪？他只是想删除一个文件（恰好是只读的）
@assylias: 奇怪与否，这肯定是一个边缘案例
@MichaelBorgwardt 那么你是说对于相同的功能有不一致的行为是可以的吗？ .. 如果是这种情况，那么 nio 不是 File API 的真正替代品，如果不一致，那么两个实现中的一个必须是正确的，另一个是错误的。
这不是很好，因为它是不可避免的，除非有一个具有严格定义的行为的官方 API，两个实现都明确声称要实现，而这里不是这种情况。

标签： java file-io nio

【解决方案1】：

正如here 所讨论的 - 问题是java.io.File 有很多奇怪之处，在 Windows 中特定。在这种情况下，它会在删除之前重置文件属性文件，所以这就是为什么它不会像预期的那样失败。它是可以追溯到> 10年的行为，因此现在改变是有风险的。它还有其他几个类似的奇怪之处，这只是它的原因之一未重新实现以使用新 API。

如果我们尝试从命令窗口中删除文件，则 windows 会抛出相同的（拒绝访问）错误，但文件会从资源管理器窗口中删除。看来File#delete() 的实现有误，应该首选新的Files#delete(Path)。

【讨论】：

能否将其扩展为更具体地解释File#delete() 做错了什么？

【解决方案2】：

为什么新旧 nio API 的相同操作会有不同的行为？

因为在新 API 的设计中，为类似操作准确模拟旧 API 的行为显然不是一个重要目标。鉴于 nio 文件系统 API 的主要目标是提供一个新的 API，它具有一些完全不同的底层概念和许多新功能，这对我来说似乎很正常。

【讨论】：