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).
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 .
: and better hack than closing and reopening: use JSR292 or
Reflection, with setAccessible(true) to invoke private method sync() of
More information about the nio-dev