Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Brian Burkhalter]

Hi Uwe,

On May 13, 2015, at 2:27 AM, Uwe Schindler <uschindler at apache.org> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150513/fb2fcfd7/attachment-0001.html>