JDK-8066915 : (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-12-08
  • Updated: 2015-06-04
  • Resolved: 2014-12-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b43Fixed
Related Reports
Relates :  
JDK-8080235 - (fs) Provide ability to flush all modified buffered data to a permanent storage device
Relates :  
JDK-8080629 - (fs) Re-enable ability to fsync() on directories even though read()s on those directories may fail.
Description
On Unix/like systems it is currently possible to open a directory for read access but subsequent reads fail. It would be more desirable for the open to fail.
Comments
Discussion thread "Recent Java 9 commit (e5b66323ae45) breaks fsync on directory" http://mail.openjdk.java.net/pipermail/nio-dev/2015-January/002979.html
12-05-2015
There is a related issue on Windows in that the IOException that is thrown is AccessDeniedException. This is because Windows returns error 5 "Access Denied" for this case. The best we can do is react to this error and attempt to check if the file is a directory. This is something for another issue.
09-12-2014
Easier fixed by checking if the file is a directory after opening the file: -- old/src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java 2014-12-08 13:04:17.512348430 +0000 +++ new/src/java.base/unix/classes/sun/nio/fs/UnixChannelFactory.java 2014-12-08 13:04:17.356348430 +0000 @@ -270,6 +270,22 @@ throw x; } + // fail if the file is a directory + if (flags.read) { + UnixException exc = null; + try { + if (UnixFileAttributes.get(fd).isDirectory()) { + exc = new UnixException(EISDIR); + } + } catch (UnixException x) { + exc = x; + } + if (exc != null) { + close(fd); + throw exc; + } + } + // unlink file immediately if delete on close. The spec is clear that // an implementation cannot guarantee to unlink the correct file when // replaced by an attacker after it is opened.
08-12-2014