Hi Uwe, On May 13, 2015, at 2:27 AM, Uwe Schindler <[email protected]> wrote:
> many thanks for opening this issue! You’re welcome! > 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. > There is one additional issue we found recently on MacOSX, but this is only > slightly related to the one here. It looks like on MacOSX, FileChannel#force > is mostly a noop regarding syncing data to disk, because the underlying > operating system requires a “special” fnctl to force buffers to disk device: > > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/fsync.2.html: > For applications that require tighter guarantees about the integrity of > their data, Mac OS X provides > the F_FULLFSYNC fcntl. The F_FULLFSYNC fcntl asks the drive to flush > all buffered data to permanent > storage. Applications, such as databases, that require a strict > ordering of writes should use F_FULLFSYNC > to ensure that their data is written in the order they expect. Please > see fcntl(2) for more > detail. > > This different behavior breaks the guarantees of FileChannel#force on MacOSX > (as described in Javadocs). So the MacOSX FileSystemProvider implementation > should use this special fnctl to force file buffers to disk. Thanks for mentioning this. I read all about the F_FULLSYNC situation yesterday in the OS X man pages. > Should I open a bug report on bugs.sun.com? I don’t think there is any need. Perhaps we can simply handle the OS X variant under this issue unless someone objects. Thanks, Brian
