Flushing ZipFS

Daniel Latrémolière daniel.latremoliere at gmail.com
Sun Jul 1 13:05:40 PDT 2012


Le 01/07/2012 19:44, Xueming Shen a écrit :
> It was debated whether or not the sync() method of the ZipFileSystem 
> should be exposed. Currently
> the sync() is only invoked when close() is being invoked with the 
> assumption that zipfs will only be
> used via the java.nio.file API, which currently does not have a 
> flush/sync method (flush/sync is more
> an implementation details of a file system). We might need to 
> re-address this issue if zipFs is being
> used by its own in JDK8 (there are couple more issues need to be 
> addressed as well).
>
> -Sherman
I think a sync()-like method is not strictly an implementation details. 
For my usage, I see this method as a feature for creating something like 
a savepoint in a ZIP file system. Clearly, this does not need exposure 
of sync() method, but probably exposure of a savepoint() method calling 
itself sync() method and possibly some others, like close() call sync().

But globally, I think now that I am asking for a bigger problem: methods 
for supporting disk coherency in Java NIO.2 FileSystem (journaling 
filesystem), which will probably be a real but much more complex 
question (and without fast response).

Thank you for your detailed response [1].
Daniel.

[1]: and better hack than closing and reopening: use JSR292 or 
Reflection, with setAccessible(true) to invoke private method sync() of 
ZipFileSystem. O:-)


More information about the nio-dev mailing list