java.nio.file.Files.isWriteable与java.io.File.canWrite()不一致

Question

我有Java代码执行以下操作:

1. 使用ZIP扩展创建临时空文件 File.createTempFile()
2. 删除它File.delete()(我们真的只想生成一个临时文件名)
3. com.google.commons.io.ByteStreams.copy()使用OutputSupplier给定相同文件名的新文件将"模板"ZIP文件复制到同一路径
4. 使用TrueZIP 7.4.3修改ZIP存档(删除目录)

在特定系统上,第4步一致失败FsReadOnlyArchiveFileSystemException - "This is a read-only archive file system!"(参见http://java.net/projects/truezip/lists/users/archive/2011-05/message/9)

调试TrueZIP代码,我注意到以下内容:

• 在上述任何步骤之间,此文件上没有打开的文件句柄,特别是在步骤4之前
• 使用File.canWrite()检查同一文件而不是NIO以完全相同的时间(使用调试器)返回,它表明它是可写的

以下是您在调试器表达式列表中看到的内容:

fn => "C:/myworkdir/temp/myfile4088293380313057223tmp.zip"
java.nio.file.Files.isWritable(java.nio.file.Paths.get(fn)) => false
new java.io.File(fn).canWrite() => true

使用JDK 1.7.04

有任何想法吗？

Answer 1

Windows下的java.nio.file.Files.isWritable中存在一个错误:它不会考虑隐式权限. java bug#7190897

Answer 2

我会避免同时使用这两个 API，而是依赖于 eg 抛出的异常new FileOutputStream()。它们至少是真实的，并且是真正值得关注的。使用您提到的 API 完全没有意义，它引入了计时窗口和重复代码。IOException无论如何，您必须抓住：为什么要两次编写所有这些代码？

Answer 3

最终结果并不太令人惊讶:

java.nio.file.Files.isWritable(java.nio.file.Paths.get(fn)) => false
new java.io.File(fn).canWrite() => true

File.canWrite根本不关注ACL,只检查MS-DOS只读属性.

Files.isWriteable注意ACL,但无论出于何种原因(为了保持损坏的程序都被破坏？),他们将File.canWrite保留为未修复.事实证明这很幸运,因为在某些情况下,即使您可以毫无问题地打开文件,它似乎也可以返回false.

真的,我会总结一下这样的方法:

• 当您无法实际写入文件时,File.canWrite有时会返回true.
• 当您可以实际写入文件时,Files.isWriteable有时会返回false.

我不确定这两种方法的重点是什么.因为每个使用它们的人最终必须写一个实际上试图打开文件的非破坏的等价物,所以人们想知道为什么他们不只是打开文件来自己进行检查.