Zip fs provider guarantees for "incomplete" operations?

[Xueming Shen]

On 01/21/2015 11:59 AM, Francis Galiegue wrote:
> The zip fs provider allows you to modify the contents of a zip using
> JSR 203 only and that's nice; however, the existing documentation is
> very poor regarding the provider in general, and also, but more
> crucially, what happens on errors.
>
> Let us forget for a moment about the bug I stumbled upon and suppose
> that it is fixed; what happens if, say, the JVM is interrupted while I
> am writing to a Path associated to a zip fs provider, in those two
> situations:
>
> * I overwrite an existing entry?
> * I create a new entry?
>
> The documentation mentions nothing about this; in fact, I believe I am
> one of the rare heavy users of this provider (outside of Oracle and of
> all people who do and don't make it public that they do, of course)
> and it has never failed on me; still, a good, solid documentation
> about this provider's behavior would be more than welcome!
>

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...

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. 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.

-Sherman