The Java 7 Zip File System is a key feature as without it Java has no means to update a zip file in a reasonably high performance way.

Unfortunately, it has a serious issue.  Attached a very short, silly test program.  It creates or updates MyTestZip.zip in the current working directory, adding or updating the file specified as the only argument, e.g. "java TestNIO2 d:\foo\bar.txt" adds a "/bar.txt" entry to the zip that is a copy of d:\foo\bar.txt.

Running this as a local Windows user in a directory that denotes permissions for non-local users fails with an exception (after a substantial and obnoxious delay).  For instance, on Windows machine D:\ has special permissions for PTCNET\jessh, my domain user.  My test local user, TEST, has read and write permissions to D:\.  Running TestNIO2 in D:\ as PTCNET\jessh works fine -- for creating or updating the target zip.  Running TestNIO2 in D:\ as TEST, however, results in an error for create or update -- even though I can clearly read and write files in this directory as this user.

The exception upon failure is:

Exception in thread "main" java.io.IOException: Unable to get effective rights from ACL: Overlapped I/O operation is in progress.
        at sun.nio.fs.WindowsFileSystemProvider.getEffectiveAccess(WindowsFileSystemProvider.java:344)
        at sun.nio.fs.WindowsFileSystemProvider.checkAccess(WindowsFileSystemProvider.java:397)
        at com.sun.nio.zipfs.ZipFileSystem.<init>(ZipFileSystem.java:124)
        at com.sun.nio.zipfs.ZipFileSystemProvider.newFileSystem(ZipFileSystemProvider.java:117)
        at java.nio.file.FileSystems.newFileSystem(FileSystems.java:322)
        at java.nio.file.FileSystems.newFileSystem(FileSystems.java:272)
        at TestNIO2.main(TestNIO2.java:33)

Understand NIO2 wants to provide a full view into OS-specific permissions and metadata, but clearly the TEST user's OS-specific view of the folder in question is working fine yet NIO2's attempt to comprehend and handle this scenario is not.

The code-level workaround is both obvious and unworkable -- to use the old ZipFile APIs and suffer from really awful performance or to use TrueZip or some such 3rd-party library.