zip4j

zip4j copied to clipboard

I am using the last release of the library.

What I have is two different servers, one where my App is running using the library and another one where I have a shared directory (SMB file share) both servers are Windows Server 2019.

On the running time, I got the following exception.

Caused by: java.io.IOException: There are no more files
at java.io.WinNTFileSystem.canonicalize0(Native Method) ~[?:?]
at java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:483) ~[?:?]
at java.io.File.getCanonicalPath(File.java:626) ~[?:?]
at net.lingala.zip4j.tasks.AbstractExtractFileTask.assertCanonicalPathsAreSame(AbstractExtractFileTask.java:75) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AbstractExtractFileTask.extractFile(AbstractExtractFileTask.java:52) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.ExtractAllFilesTask.executeTask(ExtractAllFilesTask.java:41) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.ExtractAllFilesTask.executeTask(ExtractAllFilesTask.java:17) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AsyncZipTask.performTaskWithErrorHandling(AsyncZipTask.java:51) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AsyncZipTask.execute(AsyncZipTask.java:45) ~[zip4j-2.11.1.jar:?]

First I looked for a solution for the issue in the method “java.io.File.getCanonicalPath”, but I didn’t find something that make sense for my case. What I found was an opened ticket for a similar issue in the OpenJDK project (https://bugs.openjdk.org/browse/JDK-8234363) Then I checked what the “net.lingala.zip4j.tasks.AbstractExtractFileTask.assertCanonicalPathsAreSame” method does, and I found that it is more likely a validation. So, I commented on the line where is called this method. After that my App started working properly. I already tested with local directory and remote shared directory on Windows Server 2019, and Windows 11 Home all of them x64-based processors.

@srikanth-lingala Thanks for your work on this library. Do you think this if @cquizo provides a fix it could be accepted?

Hi, I was a little busy the last days. I will look into this this week.

Canonical path check is needed to avoid a zip slip exploit. I cannot unfortunately remove this check. When you debug zip4j, what is the value of outputCanonicalPath and outputFileCanonicalPath on this line?

Hi @srikanth-lingala thanks for your response We don't know because the exception is thrown in this line as you can see here:

Caused by: java.io.IOException: There are no more files
at java.io.WinNTFileSystem.canonicalize0(Native Method) ~[?:?]
at java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:483) ~[?:?]
at java.io.File.getCanonicalPath(File.java:626) ~[?:?]
at net.lingala.zip4j.tasks.AbstractExtractFileTask.assertCanonicalPathsAreSame(AbstractExtractFileTask.java:75) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AbstractExtractFileTask.extractFile(AbstractExtractFileTask.java:52) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.ExtractAllFilesTask.executeTask(ExtractAllFilesTask.java:41) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.ExtractAllFilesTask.executeTask(ExtractAllFilesTask.java:17) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AsyncZipTask.performTaskWithErrorHandling(AsyncZipTask.java:51) ~[zip4j-2.11.1.jar:?]
at net.lingala.zip4j.tasks.AsyncZipTask.execute(AsyncZipTask.java:45) ~[zip4j-2.11.1.jar:?]

Based on my quick read on this issue, I think the bug lies somewhere in OpenJDK/Windows OS. Here is another answer which briefly explains the issue. Unfortunately, I cannot remove that check in zip4j. As I mentioned in my earlier reply, this check is to protect against a zip exploit.