JDK-8080235 : (fs) Provide ability to flush all modified buffered data to a permanent storage device
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2015-05-12
  • Updated: 2018-09-11
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8080589 - (fs) FileChannel.force should use fcntl(F_FULLFSYNC) instead of fsync on OS X
Relates :  
JDK-8066915 - (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail
Relates :  
JDK-8080629 - (fs) Re-enable ability to fsync() on directories even though read()s on those directories may fail.
Description
This issue follows from a change in undocumented behavior introduced by the JDK 9 fix of JDK-8066915. Previously in order to sync data to a directory, a FileChannel was opened in READ mode and then FileChannel.force() was invoked to flush modified in-state buffers and possibly metadata to the storage device. This behavior was however undocumented and not intended to be supported as for example a read() on the same directory FileChannel is unsupported and would provoke an exception.

The intent of this issue is to provide an alternate means to effect the desired behavior of force() within the bounds of the specification. This might call for new field definitions or new methods.
Comments
Some or all of the lines in test/java/nio/file/Files/SBC.java reverted in the patch which resolves JDK-8080629 should be examined for reinstatement as part of the fix for the current issue.
18-05-2015
Original thread about unexpected "broken" behavior: http://mail.openjdk.java.net/pipermail/nio-dev/2015-January/002979.html. Follow-on thread on the same topic: http://mail.openjdk.java.net/pipermail/nio-dev/2015-May/003140.html
12-05-2015