Path.checkAccess (6873681)

[Alan Bateman]

One of methods that needs a bit of re-work is Path's checkAccess method. 
It's an awkward operation because you either have the requested access 
or the test fails for any number of reasons. When it fails then you 
can't reliably determine if it failed because you don't have the 
requested access, or because you didn't have effective permissions to 
test the access. A couple of folks have suggested adding the equivalent 
of File's canXXX methods and there is some merit in that except that a 
simple boolean doesn't convey the reason when it fails. There is also 
the security (and performance) argument to simply remove the method as 
it isn't really needed and you are almost always better to just attempt 
access to the file and not have a window between the time of the check 
to the time of the usage. In any case, we need to do something with 
checkAccess as the exception makes it difficult to use.

One possible approach is to change checkAccess so that it doesn't throw 
an IOException but instead returns an Access or some object that 
represents the result of the check, eg:

interface Access {
  boolean isAllowed();
  IOException denyReason();
}

That would allow code such as the following:

if (file.checkAccess(READ,WRITE).isAllowed()) {
}

-or-

Access acc = file.checkAccess(EXECUTE);
if (acc.isAllowed()) {
  :
} else {
  IOException ioe = acc.denyReason();
  :
}

This approach make it trivial to implement methods such as 
exception-less isReadable, isWritable, isExecutable if they are needed.

I'm interested to hear if there are folks using checkAccess, whether the 
IOException has been a problem, and whether a solution along the lines 
here would be usable.

Thanks,

-Alan.


[1] 
http://download.java.net/jdk7/docs/api/java/nio/file/Path.html#checkAccess(java.nio.file.AccessMode...)