使用Files.delete（）删除文件时出现异常行为 请考虑以下示例java类（POM.XML）： package test.filedelete； 导入java.io.ByteArrayInputStream； 导入java.io.IOException； 导入java.io.InputStream； 导入java.io.OutputStream； 导入java.nio.file.Files； 导入java.nio.file.NoSuchFileException； 导入java.nio.file.Path； 导入org.apache.commons.io.IOUtils； 公共班机 { 公共静态void main（字符串[]args）引发IOException { byte[]bytes=“testtest”。getBytes（）； InputStream is=新的ByteArrayInputStream（字节）； 路径tempFileToBeDeleted=Files.createTempFile（“测试”，“删除”）； OutputStream os=Files.newOutputStream（tempFileToBeDeleted）； IOUtils.copy（is，os）； delete和check（tempFileToBeDeleted）； //断点1 System.out.println（“\nClosing stream\n”）； os.close（）； delete和check（tempFileToBeDeleted）； } 私有静态void deleteAndCheck（路径文件）引发IOException { System.out.println（“删除文件：+文件”）； 尝试 { 文件。删除（文件）； } 捕获（NoSuchFileException） { System.out.println（“无此类文件”）； } System.out.println（“文件真的被删除：+！Files.exists（文件））； System.out.println（“重新创建删除的文件…”）； 尝试 { 创建文件（文件）； System.out.println（“娱乐成功”）； } 捕获（IOE异常） { System.out.println（“不可能，异常：+e.getClass（）.getName（））； } } }

我写入一个FileOutputStream，然后尝试在不首先关闭流的情况下删除该文件。这是我最初的问题，当然是错误的，但它导致了一些奇怪的观察结果

在Windows 7上运行main方法时，会产生以下输出：

删除文件：C:\Users\MSCHAE~1\AppData\Local\Temp\test6100073603559201768
文件真的被删除了：真
正在重新创建已删除的文件。。。
无法重新创建，异常：java.nio.file.AccessDeniedException
关闭流
正在删除文件：C:\Users\MSCHAE~1\AppData\Local\Temp\test6100073603559201768
没有这样的档案
文件真的被删除了：真
正在重新创建已删除的文件。。。
娱乐成功

• 为什么对Files.delete（）的第一次调用不会引发异常
• 为什么下面对Files.exist（）的调用返回false
• 为什么不能重新创建文件

关于最后一个问题，我注意到当您在断点1处停止时，该文件在资源管理器中仍然可见。当您终止JVM时，该文件仍将被删除。关闭流后，deleteAndCheck（）按预期工作

在我看来，在关闭流之前，删除并没有传播到操作系统，文件API也没有正确反映这一点

有人能解释一下这里到底发生了什么吗

pom.xml

4.0.0
测试
文件删除
0.0.1-快照
公地io
公地io
2.4

澄清更新

---

如果关闭流并调用Files.delete（），则文件将在Windows资源管理器中消失-触发最后一个操作-，或者如果在未关闭流的情况下调用Files.delete（），则JVM将终止。

如果Files.delete未引发异常，则表示它已删除该文件。delete javadoc说“在某些操作系统上，当文件被此Java虚拟机或其他程序打开并使用时，可能无法删除该文件”

您可以删除打开的文件吗？

打开文件时删除文件的目录条目是完全有效的。在Unix中，这是默认语义，只要在打开该文件的所有文件句柄上设置了，Windows的行为就类似

[编辑：感谢@couling的讨论和更正]

但是，有一点不同：Unix立即删除文件名，而Windows仅在最后一个句柄关闭时删除文件名。但是，它会阻止您在关闭（已删除）文件的最后一个句柄之前打开同名文件

想想看

但是，在这两种系统上，删除文件并不一定会使文件消失，只要仍有打开的句柄，它仍会占用磁盘空间。文件占用的空间仅在关闭最后一个打开的句柄时释放

游览：Windows

有必要在Windows上指定标志，这让大多数人觉得Windows无法删除打开的文件，但事实并非如此。这只是默认行为

:

启用文件或设备上的后续打开操作以请求删除访问

否则，如果其他进程请求删除访问，则无法打开文件或设备

如果未指定此标志，但文件或设备已打开以进行删除访问，则该功能将失败。 注意：删除访问允许删除和重命名操作

:

DeleteFile函数在关闭时标记要删除的文件。因此，在关闭文件的最后一个句柄之前，不会删除文件。后续调用CreateFile以打开文件失败，错误为\u访问被拒绝

创建未命名临时文件的最典型方法之一是打开一个没有名称的文件句柄：创建一个新文件，打开它，删除文件。您现在拥有一个其他人无法打开的文件句柄。在Unix上，文件名真的消失了，在Windows上，您无法打开同名文件

现在的问题是：

是否设置

文件共享\u删除
？