On May 13, 2015, at 7:51 AM, Brian Burkhalter <[email protected]> wrote:
>> I agree with Alan that adding an OpenOption would be a good possibility. In >> any case, as Files only contains static methods, we could still add a >> “utility” method that forces file/directory buffers to disk, that just uses >> the new open option under the hood. By that FileSystem SPI interfaces do not >> need to be modified and just need to take care about the new OpenOption (if >> supported). > > I started to investigate both avenues. Alan says he has some notes on > previous work on the OpenOption avenue and I would like to see them before > proceeding much further. Getting back to this topic after a few days, I don’t know what Alan had in mind specifically with respect to OpenOption, so I am more than likely missing some subtlety. The problem I have with this approach in regards to http://download.java.net/jdk9/docs/api/java/nio/file/Files.html#newByteChannel-java.nio.file.Path-java.util.Set-java.nio.file.attribute.FileAttribute...- is the nature of the return value. In general for the case of syncing directories will this return value not be a mostly useless stub? Before https://bugs.openjdk.java.net/browse/JDK-8066915 was fixed, in the case of a directory, reading from or writing to the SeekableByteChannel returned by newByteChannel would result in either an IOException for read() or a NonWritableChannelException for write(). (One wonders “why not a NonReadableChannelException?” for the read() case unless there used to be one and this was changed (I am testing with reverted code here)). Apparently ((FileChannel)sbc).force() would work however and cause the fsync(). It seems like adding a new OpenOption specific to syncing via newByteChannel() is going to lead to a similar situation. The returned channel could be only partially functional with the non-functional methods either throwing appropriate exceptions (like before JDK-8066915), or simply being no-ops and not throwing any exceptions, the respective methods just doing the “correct” nothings. Another possibility is that the returned SeekableByteChannel is already closed, the sync having been done internally to newByteChannel(). None of these approaches is appealing to me personally as the returned value is always some form of compromised object. The other idea that was thrown about was something like Files.forceSync(Path path, boolean metadata). While this might force an update to the FileSystemProvider it seems much cleaner than returning some non- or partially functional object. From what I read the sync issue provoked by JDK-8066915 is a real problem for directories only, not files, is that correct? Any comments on the foregoing? Thanks, Brian
