-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ExtractFile Failed with NullPointExcetion #435
Comments
Do you have a stacktrace for me? |
here
When calling getFileAttributeView, the @NotNull that triggers this method causes the initialization of fileAttributeView to fail, resulting in NPE in setReadOnly in try. But I guarantee that the incoming file is non-empty, which is quite strange. By the way, When I used zip4j@1.3.2, this question didn't happen. |
srikanth-lingala
added
bug
Something isn't working
in-progress
and removed
want feedback
labels
Jun 16, 2022
srikanth-lingala
added a commit
that referenced
this issue
Jun 17, 2022
Fixed in v2.11.0 released today |
slp091020
pushed a commit
to slp091020/zip4j
that referenced
this issue
Jul 26, 2022
…Windows file attributes
srikanth-lingala
pushed a commit
that referenced
this issue
Sep 8, 2022
* Fixup #435: Add null check when getting and applying Windows file attributes * Clean up raw types Co-authored-by: Shane Parris <s@zd.is>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recently, I was doing a dependency upgrade of an old project, and planned to upgrade the original Zip4j@1.3.2 to 2.7.0, but when I did the unit test of the decompression part after the upgrade, I couldn't get the fileAttributeView normally, resulting in a null pointer exception.
I did breakpoint debugging, this path of file is non-empty, which is strange, and the folder access permission is also granted. Does the author know what happened?
The text was updated successfully, but these errors were encountered: