Zip fs provider guarantees for "incomplete" operations?

[Francis Galiegue]

On Wed, Jan 21, 2015 at 9:38 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
[...]
>
> We definitely need better "documentation" :-( The excuse is that we started
> it as
> a demo for the JSR203, then we "rushed" it in as a real/supported fs
> provider at
> the end of the release with the belief that it is easy to use and "stable"
> enough
> and might be useful for someone...
>

Well, it definitely is, and I can't thank you (personally, and OpenJDK
and Oracle) enough for providing this!

> Anyway, in both cases the bytes written into the output stream of a
> particular
> entry will not be synced back into the underlying zip file until (1)the
> output stream
> has been closed and (then) (2) the zipfs has been closed appropriately. If
> zipfs
> does not get a chance to appropriately close itself when the JVM is
> interrupted,
> all updated bytes get lost and the underlying zip file is untouched.

Well, THAT is crucial information. I could cook up some documentation
from what you said on some makeshift website, but it would be much
better if this came from an official source...

> The
> original
> implementation did have a background mechanism to sync the zipfs with its
> underlying zip file with a "timer", this feature was removed the last minute
> to
> make the implementation simpler.
>

Understandably so, I'd say. Not that partial writes are easy to
specify anyway, but this "all or nothing" policy has its merits as
well, and it's not as if this were an on-disk filesystem where the
requirements are, let's say, heavier ;)

Thanks a lot,
-- 
Francis Galiegue, fgaliegue at gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa