JDK-8014613 : (zipfs) Creating zip file system fails with "Unable to get effective rights from ACL: Overlapped I/O operation is in progress" (win)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7,7u21,7u25
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86
  • Submitted: 2013-05-14
  • Updated: 2013-05-25
  • Resolved: 2013-05-21
Related Reports
Duplicate :  
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.

not sure if this is a P3. the priority on the JDK8 bug which is a dup of this bug is P4. Can we review and adjust this bug to P4?

On 5/21/2013 10:36 AM, Roger Lewis wrote: > Hello, > > I spoke with Ingrid and we are fine to defer the bug to 7u40. > https://jbs.oracle.com/bugs/browse/JDK-8014613 > > -Roger

CAP member had confirmed it works fine with JDK 8 b90.

Member has not yet tested with JDK8 or 7u40 EA. 7u40 is being made available on java.net and they will have an opportunity to test at that point.

SQE is ok to defer to 7u40.

The fix for JDK-7190897 has been pushed to jdk7u-dev for 7u40: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/2d54c06ac56b If the CAP member is unable to test with jdk8 then it would be great if they could test with a 7u40 build that has this fix.

Closed as incomplete until we get confirmation or not that this is the same issue. The awkward aspect of this issue is that it is very hard to duplicate.

This is likely a dup of JDK-7190897. Please try a recent build of jdk8 and tell us if the problem duplicates.