java.nio.file.Files.isWriteable doesn't agree with java.io.File.canWrite()

Question

I have Java code doing the following:

1. Create a temporary empty file with ZIP extension using File.createTempFile()
2. Delete it with File.delete() (we only really wanted it to generate a temp file name)
3. Copy a "template" ZIP file to the same path with com.google.commons.io.ByteStreams.copy() using a new OutputSupplier given the same filename
4. Modify the ZIP archive (remove a directory) using TrueZIP 7.4.3

On a specific system, step 4 fails consistently with FsReadOnlyArchiveFileSystemException - "This is a read-only archive file system!" (see http://java.net/projects/truezip/lists/users/archive/2011-05/message/9)

Debugging the TrueZIP code, I noticed the following:

• There is no open file handle on this file between any of the steps above, and specifically not before step 4
• Checking the same file with File.canWrite() rather than NIO returns at the exact same timing (using a debugger), it shows that it is writable

Here is what you see in the debugger expressions list:

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

Using JDK 1.7.04

Any ideas?

Answer 1

There is a bug in java.nio.file.Files.isWritable under windows: it won't take implicit permissions into consideration. java bug #7190897

Answer 2

I would avoid using both APIs and instead rely on the exceptions thrown by e.g. new FileOutputStream(). They at least are real, and of real concern. Using the APIs you mention is entirely pointless, and it introduces timing windows and repeated code. You have to catch the IOException anyway: why write all that code twice?

Answer 3

The end result isn't too surprising:

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

File.canWrite doesn't pay attention to ACLs at all and only checks the MS-DOS read-only attribute.

Files.isWriteable pays attention to ACLs but for whatever reason (to keep broken programs broken?) they left File.canWrite un-fixed. This turns out to be lucky, because in some situations it seems like it can return false even when you can open the file with no problems.

Really, I would summarise the methods like this:

• File.canWrite sometimes returns true when you can't actually write to the file.
• Files.isWriteable sometimes returns false when you can actually write to the file.

I'm not sure what the point of either method is right now. Since everyone who uses these ultimately has to write a non-broken equivalent which actually tries to open the file, one wonders why they didn't just open the file to do the check themselves.