在远程机器上，我发现了无法复制或解释的异常。
多年来，同样的过程一直没有问题。从SCP下载多个类似的文件到RedHat Linux上的共享网络位置，确保磁盘上有可用空间，并且所有权限都很好。只有几个文件描述符打开。今天，突然之间，在写完最后一个文件的同时，{strong}关闭了<{1}}，然后关闭了，但文件已正确保存。
此类例外的可能原因是什么？除了java.io.IOException: Permission denied到Permission denied的映射外，我还没有在Java源代码中找到任何内容。在浏览互联网时，我只发现人们在打开流时获得EACCES但未关闭它的情况。
Permission denied答案 0 :(得分：2)
这只是一个理论......
查看Linux内核源代码，似乎在某些情况下，close(fd)系统调用将在关闭之前尝试执行内部刷新。如果fd与“文件系统”上的文件关联，而文件打开时可以更改有效的访问权限，那么可以想象关闭的刷新可能会失败，因为当前权限过于严格。这将变成EACCES系统调用失败。
这样的失败很少见，因为文件的许可在恰当的“正确”时间发生变化以触发失败是不常见的;即在close系统调用和之前的write系统调用之间。
此外，可以想象这只会发生在某些类型的文件中;例如远程文件服务器上的文件，远程服务器实现访问控制。
请注意，Linux手册条目或POSIX规范并未设想使用EACCES失败的close()。文档暗示仅在打开文件时检查访问，这（至少）是意外行为。
然而，另一方面，（虚拟）文件系统行为的各个方面依赖于文件系统本身的实现。在某些情况下，文件系统不会“正常”运行。