Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

Alan Bateman Alan.Bateman at
Tue May 12 21:11:18 UTC 2015

On 12/05/2015 19:59, Uwe Schindler wrote:
> Hallo Alan,
> I just wanted to come back to this issue, because there was no further communication recently regarding the behavior of Java 9 with opening a FileChannel on a directory to fsync the directory metadata. Unfortunately, this would break the improved data safety after commits to Apache Lucene indexes. This would affect many applications like Apache Solr and Elasticsearch that rely on fsyncing the metadata on UNIX systems (Linux, Solaris, MacOSX). Recently Elasticsearch also started to use the same approach for its transaction log! Because we (Apache Lucene) use atomic rename functionality to "publish" commits, losing the directory metadata after a power failure loses all data in the commit done before the failure. With Java 7 and Java 8 we already did extensive tests with remote controlled power plugs switching a test machine on and off and validating that index was intact. This is no longer working with Java 9 because of the change.
> Our question now: The discussion was, to allow maybe another OpenOption to do such special stuff, that is important for other databases, too (I assume, Apache Derby, HSQLDB or other databases written in Java would like to do similar things). Is there anything we can do to make a proposal for a new API, like starting a JEP, opening a bug report,... I would take the opportunity to get involved into the OpenJDK project to help and bring this forward.
> Maybe instead of complex open options, we should simply add a new method to the Files class: Files.force/fsync(Path fileOrDir, boolean metadata) that does the right thing depending on the file / operating system?
I've been too busy with other JDK 9 work to spend on time on this issue 
recently. I do think we should introduce some support for this use-case 
as it's clearly important.

The issue with adding a method to Files is that it requires rev'ing the 
service provider interface so this is why I brought up the possibility 
of have it work as an OpenOption.

We should start by creating a bug on. Brian Burkhalter may have created 
one already.


More information about the nio-dev mailing list