[jira] [Commented] (BCEL-279) Utility.methodSignature* throw ClassFormatException when converting binary names with generics.
[
https://issues.apache.org/jira/browse/BCEL-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904303#comment-16904303
]
Gary Gregory commented on BCEL-279:
---
[~markro],
Did you rebase your patch on git master.
I am getting:
{nofomat}
git apply c:\temp\bcel279.patch.txt
error: patch failed:
src/main/java/org/apache/bcel/classfile/LocalVariable.java:26
error: src/main/java/org/apache/bcel/classfile/LocalVariable.java: patch does
not apply
{noformat}
May you please provide a GitHub PR instead?
Thank you,
Gary
> Utility.methodSignature* throw ClassFormatException when converting binary
> names with generics.
> ---
>
> Key: BCEL-279
> URL: https://issues.apache.org/jira/browse/BCEL-279
> Project: Commons BCEL
> Issue Type: Bug
> Components: Parser
>Affects Versions: 6.0
>Reporter: Dongsun Kim
>Priority: Major
> Fix For: 6.x
>
> Attachments: bcel279.patch
>
>
> When I try the following, Utility class throws ClassFormatException:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignatureArgumentTypes(sig, false)
> {code}
> The above signature actually exists in com.google.common.io.ByteSource in
> Google Guava.
> Utility.methodSignatureReturnType does not throw any exception but its return
> value does not look valid.
> When I try this:
> {code}
> String sig =
> "(Lcom/google/common/io/ByteProcessor;)TT;"
> Utility.methodSignaturerReturnType(sig, false)
> {code}
> expected: java.lang.Object
> actual: T
> It seems that org.apache.bcel.generic.Type.java also has the same issue.
> Dongsun.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-vfs] garydgregory commented on issue #68: VFS-724: fixed bug in case of no content-length
garydgregory commented on issue #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68#issuecomment-520090137 Please realize that some of us here have spent a tremendous amount of time on this project already over the years. I feel like asking you to give back a little more in the form of a complete PR in return for free and open source software is fair. You might need to adjust your expectations... Furthermore, learning about mocking is a benefit I would not neglect. Pointing at other tests and saying these are not so great either is not, IMO, a justification for perpetuating an antipattern. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] wrey75 commented on issue #68: VFS-724: fixed bug in case of no content-length
wrey75 commented on issue #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68#issuecomment-520088228 I have written the unit test based on the previous one found in the same class and involving the Apache website, not a mock. I think I've done my best with this bug: I've made a unit test which fails with the current code, made the fix and provided a PR. I know the unit test is not very stable in the long term but couldn't I rely on some guys invested in the project to write the proper test? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on issue #68: VFS-724: fixed bug in case of no content-length
garydgregory commented on issue #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68#issuecomment-520085096 I am not a huge fan of mocking but this is a great example of when you would really want to do so. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] michael-o commented on issue #68: VFS-724: fixed bug in case of no content-length
michael-o commented on issue #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68#issuecomment-520080892 What gives you the certainty that this test won't break next month when the target changes? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-vfs] wrey75 commented on issue #68: VFS-724: fixed bug in case of no content-length
wrey75 commented on issue #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68#issuecomment-520078786 Well, I can change the URL to "http://www.apache.org/dist/"; which is returning a page without content-length but doing a mock seems lots of work and there is also a test involving the "apache.org" website in the same class. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Reopened] (VFS-725) [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
[
https://issues.apache.org/jira/browse/VFS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory reopened VFS-725:
--
> [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing
> milliseconds (always ends in 000)
> -
>
> Key: VFS-725
> URL: https://issues.apache.org/jira/browse/VFS-725
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.5
>
>
> For the [Local] file system,
> {{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} is losing
> milliseconds (always ends in 000).
> This is because {{File.lastModified()}} is losing milliseconds (always ends
> in 000)
> This is only on OpenJDK 8 and 9:
> https://bugs.openjdk.java.net/browse/JDK-8177809
> The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
> call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (VFS-725) [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
[
https://issues.apache.org/jira/browse/VFS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-725.
Resolution: Fixed
> [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing
> milliseconds (always ends in 000)
> -
>
> Key: VFS-725
> URL: https://issues.apache.org/jira/browse/VFS-725
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.5
>
>
> The [Local] file system,
> {{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} method is
> losing milliseconds (always ends in 000).
> This is because {{File.lastModified()}} is losing milliseconds (always ends
> in 000)
> This is only on OpenJDK 8 and 9:
> [https://bugs.openjdk.java.net/browse/JDK-8177809]
> The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
> call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (VFS-725) [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
[
https://issues.apache.org/jira/browse/VFS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-725:
-
Description:
The [Local] file system,
{{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} method is losing
milliseconds (always ends in 000).
This is because {{File.lastModified()}} is losing milliseconds (always ends in
000)
This is only on OpenJDK 8 and 9:
[https://bugs.openjdk.java.net/browse/JDK-8177809]
The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
was:
For the [Local] file system,
{{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} is losing
milliseconds (always ends in 000).
This is because {{File.lastModified()}} is losing milliseconds (always ends in
000)
This is only on OpenJDK 8 and 9:
https://bugs.openjdk.java.net/browse/JDK-8177809
The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
> [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing
> milliseconds (always ends in 000)
> -
>
> Key: VFS-725
> URL: https://issues.apache.org/jira/browse/VFS-725
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.5
>
>
> The [Local] file system,
> {{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} method is
> losing milliseconds (always ends in 000).
> This is because {{File.lastModified()}} is losing milliseconds (always ends
> in 000)
> This is only on OpenJDK 8 and 9:
> [https://bugs.openjdk.java.net/browse/JDK-8177809]
> The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
> call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (VFS-725) [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
[
https://issues.apache.org/jira/browse/VFS-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-725.
Resolution: Fixed
Fix Version/s: 2.5
In git master.
> [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing
> milliseconds (always ends in 000)
> -
>
> Key: VFS-725
> URL: https://issues.apache.org/jira/browse/VFS-725
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 2.5
>
>
> For the [Local] file system,
> {{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} is losing
> milliseconds (always ends in 000).
> This is because {{File.lastModified()}} is losing milliseconds (always ends
> in 000)
> This is only on OpenJDK 8 and 9:
> https://bugs.openjdk.java.net/browse/JDK-8177809
> The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
> call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (VFS-725) [Local] org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
Gary Gregory created VFS-725:
Summary: [Local]
org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing
milliseconds (always ends in 000)
Key: VFS-725
URL: https://issues.apache.org/jira/browse/VFS-725
Project: Commons VFS
Issue Type: Bug
Reporter: Gary Gregory
For the [Local] file system,
{{org.apache.commons.vfs2.FileContent.getLastModifiedTime()}} is losing
milliseconds (always ends in 000).
This is because {{File.lastModified()}} is losing milliseconds (always ends in
000)
This is only on OpenJDK 8 and 9:
https://bugs.openjdk.java.net/browse/JDK-8177809
The workaround is for {{org.apache.commons.vfs2.provider.local.LocalFile}} to
call {{Files.getLastModifiedTime}} instead of {{File.lastModified()}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-vfs] michael-o commented on a change in pull request #68: VFS-724: fixed bug in case of no content-length
michael-o commented on a change in pull request #68: VFS-724: fixed bug in case
of no content-length
URL: https://github.com/apache/commons-vfs/pull/68#discussion_r312656714
##
File path:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/http4/test/Http4GetContentInfoTest.java
##
@@ -56,4 +59,13 @@ public void testGetContentInfo() throws FileSystemException
{
// Used to NPE before fix:
content.getContentInfo();
}
+
+
+@Test
+public void testGetZeroContents() throws IOException {
+final FileSystemManager fsManager = VFS.getManager();
+final FileObject fo =
fsManager.resolveFile("http4://monpremierlivre.home.blog/");
Review comment:
I'd rather see a local server here because this test requires outbound
access and is brittle.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-vfs] garydgregory commented on a change in pull request #68: VFS-724: fixed bug in case of no content-length
garydgregory commented on a change in pull request #68: VFS-724: fixed bug in
case of no content-length
URL: https://github.com/apache/commons-vfs/pull/68#discussion_r312655320
##
File path:
commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/http4/test/Http4GetContentInfoTest.java
##
@@ -56,4 +59,13 @@ public void testGetContentInfo() throws FileSystemException
{
// Used to NPE before fix:
content.getContentInfo();
}
+
+
+@Test
+public void testGetZeroContents() throws IOException {
+final FileSystemManager fsManager = VFS.getManager();
+final FileObject fo =
fsManager.resolveFile("http4://monpremierlivre.home.blog/");
Review comment:
I think you will want to use Mockito here instead of depending on a random
third party web site -- random from Apache's POV ;-)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (VFS-724) FileContentt#getByteArray() throw Exception
[
https://issues.apache.org/jira/browse/VFS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904203#comment-16904203
]
William Rey commented on VFS-724:
-
PR#68 (https://github.com/apache/commons-vfs/pull/68) submitted.
> FileContentt#getByteArray() throw Exception
> ---
>
> Key: VFS-724
> URL: https://issues.apache.org/jira/browse/VFS-724
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: William Rey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current code only checks for a size bigger than 2MB but ignores when the
> returned size is 0 or negative. {{sizeL}} will be typically equals to zero if
> the request is made to a WebServer and the response generated live (like
> PHP). Then the {{getInputStream(size)}} will fail in this case when the size
> is really used by the implementation.
> {code}
> default byte[] getByteArray() throws IOException {
> final long sizeL = getSize();
> if (sizeL > Integer.MAX_VALUE) {
> throw new IllegalStateException(String.format("File content is
> too large for a byte array: %,d", sizeL));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Work logged] (VFS-724) FileContentt#getByteArray() throw Exception
[
https://issues.apache.org/jira/browse/VFS-724?focusedWorklogId=292257&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-292257
]
ASF GitHub Bot logged work on VFS-724:
--
Author: ASF GitHub Bot
Created on: 09/Aug/19 21:26
Start Date: 09/Aug/19 21:26
Worklog Time Spent: 10m
Work Description: wrey75 commented on pull request #68: VFS-724: fixed
bug in case of no content-length
URL: https://github.com/apache/commons-vfs/pull/68
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 292257)
Time Spent: 10m
Remaining Estimate: 0h
> FileContentt#getByteArray() throw Exception
> ---
>
> Key: VFS-724
> URL: https://issues.apache.org/jira/browse/VFS-724
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: William Rey
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The current code only checks for a size bigger than 2MB but ignores when the
> returned size is 0 or negative. {{sizeL}} will be typically equals to zero if
> the request is made to a WebServer and the response generated live (like
> PHP). Then the {{getInputStream(size)}} will fail in this case when the size
> is really used by the implementation.
> {code}
> default byte[] getByteArray() throws IOException {
> final long sizeL = getSize();
> if (sizeL > Integer.MAX_VALUE) {
> throw new IllegalStateException(String.format("File content is
> too large for a byte array: %,d", sizeL));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-vfs] wrey75 opened a new pull request #68: VFS-724: fixed bug in case of no content-length
wrey75 opened a new pull request #68: VFS-724: fixed bug in case of no content-length URL: https://github.com/apache/commons-vfs/pull/68 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (EXEC-110) Two issues in the tutorial of commons-exec
[
https://issues.apache.org/jira/browse/EXEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904192#comment-16904192
]
Gary Gregory commented on EXEC-110:
---
[~wlei1818],
Thank you for your report. May you please create a PR on GitHub at
[https://github.com/apache/commons-exec] ?
Thank you,Gary
> Two issues in the tutorial of commons-exec
> --
>
> Key: EXEC-110
> URL: https://issues.apache.org/jira/browse/EXEC-110
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Lei Wang
>Priority: Major
>
> I found two obvious issues in the tutoral of commons-exec in the section of
> "Unblock Your Execution".
> with the provided sample code of "commandLine.setSubstitutionMap(map);", the
> variable "commandLine" is different with "cmdLine" as abouve.
> {code:java}
> CommandLine cmdLine = new CommandLine("AcroRd32.exe");
> cmdLine.addArgument("/p");
> cmdLine.addArgument("/h");
> cmdLine.addArgument("${file}");
> HashMap map = new HashMap();
> map.put("file", new File("invoice.pdf"));
> commandLine.setSubstitutionMap(map);
> {code}
>
> the code "int exitValue = resultHandler.waitFor();" also has a mistake.
> because with the api definition, the method of "waitFor()" have the "void"
> return type, maybe you want to invoke "getExitValue()" which will return int
> type.
> {code:java}
> int exitValue = resultHandler.waitFor();
> {code}
>
> attach the links for your refarance.
> [http://commons.apache.org/proper/commons-exec/tutorial.html]
> [http://commons.apache.org/proper/commons-exec/apidocs/index.html]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (EXEC-110) Two issues in the tutorial of commons-exec
[
https://issues.apache.org/jira/browse/EXEC-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904192#comment-16904192
]
Gary Gregory edited comment on EXEC-110 at 8/9/19 9:17 PM:
---
[~wlei1818],
Thank you for your report. May you please create a PR on GitHub at
[https://github.com/apache/commons-exec] ?
Thank you,
Gary
was (Author: garydgregory):
[~wlei1818],
Thank you for your report. May you please create a PR on GitHub at
[https://github.com/apache/commons-exec] ?
Thank you,Gary
> Two issues in the tutorial of commons-exec
> --
>
> Key: EXEC-110
> URL: https://issues.apache.org/jira/browse/EXEC-110
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Lei Wang
>Priority: Major
>
> I found two obvious issues in the tutoral of commons-exec in the section of
> "Unblock Your Execution".
> with the provided sample code of "commandLine.setSubstitutionMap(map);", the
> variable "commandLine" is different with "cmdLine" as abouve.
> {code:java}
> CommandLine cmdLine = new CommandLine("AcroRd32.exe");
> cmdLine.addArgument("/p");
> cmdLine.addArgument("/h");
> cmdLine.addArgument("${file}");
> HashMap map = new HashMap();
> map.put("file", new File("invoice.pdf"));
> commandLine.setSubstitutionMap(map);
> {code}
>
> the code "int exitValue = resultHandler.waitFor();" also has a mistake.
> because with the api definition, the method of "waitFor()" have the "void"
> return type, maybe you want to invoke "getExitValue()" which will return int
> type.
> {code:java}
> int exitValue = resultHandler.waitFor();
> {code}
>
> attach the links for your refarance.
> [http://commons.apache.org/proper/commons-exec/tutorial.html]
> [http://commons.apache.org/proper/commons-exec/apidocs/index.html]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (VFS-724) FileContentt#getByteArray() throw Exception
[
https://issues.apache.org/jira/browse/VFS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904186#comment-16904186
]
William Rey commented on VFS-724:
-
I have added the following test in
{{org.apache.commons.vfs2.provider.http4.test.Http4GetContentInfoTest}}
{code:java}
@Test
public void testGetZeroContents() throws IOException {
final FileSystemManager fsManager = VFS.getManager();
final FileObject fo =
fsManager.resolveFile("http4://monpremierlivre.home.blog/");
final FileContent content = fo.getContent();
Assert.assertNotNull(content.getString(StandardCharsets.UTF_8));
// Used to NPE before fix:
content.getContentInfo();
}
{code}
and fails with the following:
{code}
java.lang.IllegalArgumentException: Buffer size <= 0
at java.io.BufferedInputStream.(BufferedInputStream.java:201)
at
org.apache.commons.vfs2.util.MonitorInputStream.(MonitorInputStream.java:51)
at
org.apache.commons.vfs2.provider.DefaultFileContent$FileContentInputStream.(DefaultFileContent.java:619)
at
org.apache.commons.vfs2.provider.DefaultFileContent.buildInputStream(DefaultFileContent.java:499)
at
org.apache.commons.vfs2.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:356)
at
org.apache.commons.vfs2.FileContent.getByteArray(FileContent.java:134)
at org.apache.commons.vfs2.FileContent.getString(FileContent.java:283)
at
org.apache.commons.vfs2.provider.http4.test.Http4GetContentInfoTest.testGetZeroContents(Http4GetContentInfoTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{code}
Note the page requested is a Wordpress generated-page (not a static one) then
the {Content-length}} is zero (not given) then of course trying to read in an
empty buffer raises an exception. I don't know the best way to fix it.
I try to open an issue in GitHub with a fix.
> FileContentt#getByteArray() throw Exception
> ---
>
> Key: VFS-724
> URL: https://issues.apache.org/jira/browse/VFS-724
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: William Rey
>Priority: Major
>
> The current code only checks for a size bigger than 2MB but ignores when the
> returned size is 0 or negative. {{sizeL}} will be typically equals to zero if
> the request is made to a WebServer and the response generated live (like
> PHP). Then the {{getInputStream(size)}} will fail in this case when the size
> is really used by the implementation.
> {code}
> default byte[] getByteArray() throws IOException {
> final long sizeL = getSize();
> if (sizeL > Integer.MAX_VALUE) {
> throw new IllegalStateException(String.format("File content is
> too large for a byte array: %,d", sizeL));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-lang] michael-o closed pull request #438: Add files via upload
michael-o closed pull request #438: Add files via upload URL: https://github.com/apache/commons-lang/pull/438 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VFS-724) FileContentt#getByteArray() throw Exception
[
https://issues.apache.org/jira/browse/VFS-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904178#comment-16904178
]
Gary Gregory commented on VFS-724:
--
Size 0 sounds legal to me since it represents an empty file. Otherwise a
negative size seems bogus. We welcome PRs on GitHub; -)
> FileContentt#getByteArray() throw Exception
> ---
>
> Key: VFS-724
> URL: https://issues.apache.org/jira/browse/VFS-724
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: William Rey
>Priority: Major
>
> The current code only checks for a size bigger than 2MB but ignores when the
> returned size is 0 or negative. {{sizeL}} will be typically equals to zero if
> the request is made to a WebServer and the response generated live (like
> PHP). Then the {{getInputStream(size)}} will fail in this case when the size
> is really used by the implementation.
> {code}
> default byte[] getByteArray() throws IOException {
> final long sizeL = getSize();
> if (sizeL > Integer.MAX_VALUE) {
> throw new IllegalStateException(String.format("File content is
> too large for a byte array: %,d", sizeL));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (VFS-724) FileContentt#getByteArray() throw Exception
William Rey created VFS-724:
---
Summary: FileContentt#getByteArray() throw Exception
Key: VFS-724
URL: https://issues.apache.org/jira/browse/VFS-724
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.4
Reporter: William Rey
The current code only checks for a size bigger than 2MB but ignores when the
returned size is 0 or negative. {{sizeL}} will be typically equals to zero if
the request is made to a WebServer and the response generated live (like PHP).
Then the {{getInputStream(size)}} will fail in this case when the size is
really used by the implementation.
{code}
default byte[] getByteArray() throws IOException {
final long sizeL = getSize();
if (sizeL > Integer.MAX_VALUE) {
throw new IllegalStateException(String.format("File content is too
large for a byte array: %,d", sizeL));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-lang] doodeehee70 commented on issue #438: Add files via upload
doodeehee70 commented on issue #438: Add files via upload URL: https://github.com/apache/commons-lang/pull/438#issuecomment-520055985 A This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] coveralls commented on issue #438: Add files via upload
coveralls commented on issue #438: Add files via upload URL: https://github.com/apache/commons-lang/pull/438#issuecomment-520041082 [](https://coveralls.io/builds/25091754) Coverage decreased (-0.01%) to 95.328% when pulling **2e21023db9033110b1abc21762a0faf8fe6d01be on doodeehee70:master** into **1d037da2a85c920af7ab8aa96fa7529d5b4584b7 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] doodeehee70 commented on issue #438: Add files via upload
doodeehee70 commented on issue #438: Add files via upload URL: https://github.com/apache/commons-lang/pull/438#issuecomment-520038433 A This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] doodeehee70 opened a new pull request #438: Add files via upload
doodeehee70 opened a new pull request #438: Add files via upload URL: https://github.com/apache/commons-lang/pull/438 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] coveralls commented on issue #437: Add GenericArrayType support to TypeUtils.containsTypeVariables
coveralls commented on issue #437: Add GenericArrayType support to TypeUtils.containsTypeVariables URL: https://github.com/apache/commons-lang/pull/437#issuecomment-520031645 [](https://coveralls.io/builds/25091155) Coverage decreased (-0.02%) to 95.323% when pulling **138878b3609c65fe01c57e96f41754b806016404 on dimitrovchi:master** into **1d037da2a85c920af7ab8aa96fa7529d5b4584b7 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] dimitrovchi opened a new pull request #437: Add GenericArrayType support to TypeUtils.containsTypeVariables
dimitrovchi opened a new pull request #437: Add GenericArrayType support to TypeUtils.containsTypeVariables URL: https://github.com/apache/commons-lang/pull/437 Currently, org.apache.commons.lang3.reflect.TypeUtils#containsTypeVariables doesn't contain a special case for GenericArrayType like E[], so if the passed argument is a GenericArrayType instance containing type variables, this method will return false. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (COMPRESS-487) PKWARE DCL Implode support (ZIP compression method 10)
[
https://issues.apache.org/jira/browse/COMPRESS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904105#comment-16904105
]
Emmanuel Bourg commented on COMPRESS-487:
-
I now have a working implementation, it just needs some cleanup/testing and
I'll commit it.
> PKWARE DCL Implode support (ZIP compression method 10)
> --
>
> Key: COMPRESS-487
> URL: https://issues.apache.org/jira/browse/COMPRESS-487
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers, Compressors
>Reporter: Emmanuel Bourg
>Assignee: Emmanuel Bourg
>Priority: Minor
> Labels: zip
> Attachments: dclimplode-ascii-1024.zip, dclimplode-ascii-2048.zip,
> dclimplode-ascii-4096.zip, dclimplode-binary-1024.zip,
> dclimplode-binary-2048.zip, dclimplode-binary-4096.zip
>
>
> Commons Compress doesn't yet support the implode compression algorithm
> implemented in the PKWARE Data Compression Library (DCL). This algorithm can
> be used in ZIP files (using the compression method 10, which differs from the
> other implode compression method 6 already supported). It's also used in some
> old file formats like dBASE/xBase and game files from the 90's (.mpq).
> ZIP files using this compression method can be created with recent versions
> of the [PKWARE ZIP Compression Utility|https://www.pkware.com/pkzip]. The
> syntax looks like this:
> {{pkzipc -add -dclimplode=ascii,4096 test.zip *.txt}}
> The format is documented here:
> https://groups.google.com/forum/#!msg/comp.compression/M5P064or93o/W1ca1-ad6kgJ
> and here is the implementation in zlib:
> https://github.com/madler/zlib/blob/master/contrib/blast/blast.c
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-487) PKWARE DCL Implode support (ZIP compression method 10)
[
https://issues.apache.org/jira/browse/COMPRESS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated COMPRESS-487:
Assignee: Emmanuel Bourg
> PKWARE DCL Implode support (ZIP compression method 10)
> --
>
> Key: COMPRESS-487
> URL: https://issues.apache.org/jira/browse/COMPRESS-487
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers, Compressors
>Reporter: Emmanuel Bourg
>Assignee: Emmanuel Bourg
>Priority: Minor
> Labels: zip
> Attachments: dclimplode-ascii-1024.zip, dclimplode-ascii-2048.zip,
> dclimplode-ascii-4096.zip, dclimplode-binary-1024.zip,
> dclimplode-binary-2048.zip, dclimplode-binary-4096.zip
>
>
> Commons Compress doesn't yet support the implode compression algorithm
> implemented in the PKWARE Data Compression Library (DCL). This algorithm can
> be used in ZIP files (using the compression method 10, which differs from the
> other implode compression method 6 already supported). It's also used in some
> old file formats like dBASE/xBase and game files from the 90's (.mpq).
> ZIP files using this compression method can be created with recent versions
> of the [PKWARE ZIP Compression Utility|https://www.pkware.com/pkzip]. The
> syntax looks like this:
> {{pkzipc -add -dclimplode=ascii,4096 test.zip *.txt}}
> The format is documented here:
> https://groups.google.com/forum/#!msg/comp.compression/M5P064or93o/W1ca1-ad6kgJ
> and here is the implementation in zlib:
> https://github.com/madler/zlib/blob/master/contrib/blast/blast.c
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (IO-618) Add classes Added TaggedReader, ClosedReader and BrokenReader. #85.
[ https://issues.apache.org/jira/browse/IO-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed IO-618. --- Resolution: Fixed Fix Version/s: 2.7 In git master. > Add classes Added TaggedReader, ClosedReader and BrokenReader. #85. > --- > > Key: IO-618 > URL: https://issues.apache.org/jira/browse/IO-618 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.7 > > > Add classes Added TaggedReader, ClosedReader and BrokenReader. #85. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IO-618) Add classes Added TaggedReader, ClosedReader and BrokenReader. #85.
Gary Gregory created IO-618: --- Summary: Add classes Added TaggedReader, ClosedReader and BrokenReader. #85. Key: IO-618 URL: https://issues.apache.org/jira/browse/IO-618 Project: Commons IO Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add classes Added TaggedReader, ClosedReader and BrokenReader. #85. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [commons-io] garydgregory merged pull request #85: Added TaggedReader, ClosedReader and BrokenReader.
garydgregory merged pull request #85: Added TaggedReader, ClosedReader and BrokenReader. URL: https://github.com/apache/commons-io/pull/85 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (RNG-111) Jenkins Small Fast generator
[ https://issues.apache.org/jira/browse/RNG-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904075#comment-16904075 ] Abhishek Singh Dhadwal commented on RNG-111: Hello [~aherbert], I'd like to work on this issue. The github link is provided here : https://github.com/AbhishekSinghDhadwal/commons-rng/tree/feature-RNG-111 > Jenkins Small Fast generator > > > Key: RNG-111 > URL: https://issues.apache.org/jira/browse/RNG-111 > Project: Commons RNG > Issue Type: Improvement > Components: core >Affects Versions: 1.3 >Reporter: Alex D Herbert >Priority: Minor > > Implement Bob Jenkins' Small/Fast Chaotic PRNG. > [A small noncryptographic > PRNG|http://burtleburtle.net/bob/rand/smallprng.html] > Variants are provided for 32-bit and 64-bit output. The generators use bit > shifts to avalanche state and many variants are provided for different shift > combinations. However there is a recommended variant that has been more > extensively tested. A seeding routine is provided to ensure that generators > with short cycles are avoided. > This generator has no name but appears in PractRand as JSF (Jenkins Small > Fast). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (COMPRESS-470) ParallelScatterZipCreator leaks temporary files (and maybe more)
[
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904048#comment-16904048
]
Melloware commented on COMPRESS-470:
Nice work and much appreciation for your continued work on this library!
> ParallelScatterZipCreator leaks temporary files (and maybe more)
>
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
>
> As indicated by
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679878#comment-16679878
> COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-481) Allow passing memory limit for extraction to SevenZFile
[ https://issues.apache.org/jira/browse/COMPRESS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-481: Labels: 7z (was: ) > Allow passing memory limit for extraction to SevenZFile > --- > > Key: COMPRESS-481 > URL: https://issues.apache.org/jira/browse/COMPRESS-481 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Robin Schimpf >Priority: Major > Labels: 7z > Fix For: 1.19 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I am handling arbitrary 7zip files in my application. The extraction of the > files happens parallelized. To have better control how much memory a single > file uses for extraction it would be good to be able to pass the memory > limitation to the SevenZFile. > This is already possible when using the CompressorStreamFactory. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-481) Allow passing memory limit for extraction to SevenZFile
[ https://issues.apache.org/jira/browse/COMPRESS-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-481: Component/s: Archivers > Allow passing memory limit for extraction to SevenZFile > --- > > Key: COMPRESS-481 > URL: https://issues.apache.org/jira/browse/COMPRESS-481 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Robin Schimpf >Priority: Major > Fix For: 1.19 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I am handling arbitrary 7zip files in my application. The extraction of the > files happens parallelized. To have better control how much memory a single > file uses for extraction it would be good to be able to pass the memory > limitation to the SevenZFile. > This is already possible when using the CompressorStreamFactory. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-486) Expander causes "Cleaning up unclosed ZipFile" to be written to stderr
[
https://issues.apache.org/jira/browse/COMPRESS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-486:
Component/s: Examples
> Expander causes "Cleaning up unclosed ZipFile" to be written to stderr
> --
>
> Key: COMPRESS-486
> URL: https://issues.apache.org/jira/browse/COMPRESS-486
> Project: Commons Compress
> Issue Type: Bug
> Components: Examples
>Affects Versions: 1.18
> Environment: Java 1.8, Windows 10, IntelliJ 2018.2.7
>Reporter: Jordan Piscitelli
>Priority: Minor
> Fix For: 1.19
>
>
> Using the Expander, I found that it will create a zip file that is not closed
> which results in an error message being written to std-err when garbage
> collection (and finalization) occurs.
> I believe it is [line 140 of the
> Expander|https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L140]
> as it creates a zip file that does not appear to be closed.
> {code:java}
> 140: expand(new ZipFile(archive), targetDirectory);{code}
> I have created a test that demonstrates the behavior. It runs
> Expander.expand(file, file) followed by garbage collection and finalize, and
> passes if stderr was not written to.
> Currently the test fails as "Cleaning up unclosed ZipFile for archive unknown
> archive" is written to stderr.
> {code:java}
> import java.io.ByteArrayOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> import java.io.PrintStream;
> import java.nio.charset.StandardCharsets;
> import org.apache.commons.compress.archivers.ArchiveException;
> import org.apache.commons.compress.archivers.ArchiveOutputStream;
> import org.apache.commons.compress.archivers.ArchiveStreamFactory;
> import org.apache.commons.compress.archivers.examples.Expander;
> import org.codehaus.plexus.util.StringUtils;
> import org.junit.jupiter.api.Test;
> import org.springframework.util.Assert;
> public class ExpanderCloseTest {
> @Test
> public void testExpanderClosesZipFile() {
> final ByteArrayOutputStream errOutputStream = new
> ByteArrayOutputStream();
> try {
> final File sourceArchiveFile = createSampleZip();
> final File targetExpansionDirectory =
> File.createTempFile("dest.zip", null);
> try (PrintStream ps = new PrintStream(errOutputStream, true,
> "UTF-8")) {
> System.setErr(ps);
> Expander expander = new Expander();
> expander.expand(sourceArchiveFile, targetExpansionDirectory);
> System.gc();
> System.runFinalization();
> }
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> String stderr = new String(errOutputStream.toByteArray(),
> StandardCharsets.UTF_8);
> Assert.isTrue(StringUtils.isBlank(stderr), "Nothing should have been
> written to stderr, but this was: " + stderr);
> }
> private File createSampleZip() throws IOException, ArchiveException {
> final File sourceArchiveFile = File.createTempFile("example.zip",
> null);
> OutputStream archiveStream = new FileOutputStream(sourceArchiveFile);
> ArchiveOutputStream archive = new
> ArchiveStreamFactory().createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> archiveStream);
> archive.finish();
> archiveStream.close();
> return sourceArchiveFile;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-490) [lz4] Multiple unchecked exceptions when decompressing malformed input
[
https://issues.apache.org/jira/browse/COMPRESS-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-490:
Labels: lz4 (was: )
> [lz4] Multiple unchecked exceptions when decompressing malformed input
> --
>
> Key: COMPRESS-490
> URL: https://issues.apache.org/jira/browse/COMPRESS-490
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.18
> Environment: MacOS Mojave
> openjdk version "1.8.0_212"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode)
>Reporter: Alex Rebert
>Priority: Minor
> Labels: lz4
> Fix For: 1.19
>
> Attachments: ArithmeticException, ArrayIndexOutOfBoundsException1,
> ArrayIndexOutOfBoundsException2
>
>
> Encountered multiple unchecked exceptions thrown from
> {{FramedLZ4CompressorInputStream.read}} when parsing malformed files.
> {{ArrayIndexOutOfBoundsException}} and {{ArithmeticException}} are unchecked
> exceptions that are not documented in this API; therefore, such exceptions
> can cause stability issues in applications that are not expecting them.
> Instead, an {{IOException}} should be thrown indicating that the input stream
> contains malformed data.
> Stack traces for three distinct (but possibly related) sources of exceptions
> follow:
> {noformat}
> java.lang.ArithmeticException: / by zero
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.tryToCopy(AbstractLZ77CompressorInputStream.java:314)
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.readBackReference(AbstractLZ77CompressorInputStream.java:291)
> at
> org.apache.commons.compress.compressors.lz4.BlockLZ4CompressorInputStream.read(BlockLZ4CompressorInputStream.java:83)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.readOnce(FramedLZ4CompressorInputStream.java:328)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.read(FramedLZ4CompressorInputStream.java:145)
> at java.io.InputStream.read(InputStream.java:101)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.tryToCopy(AbstractLZ77CompressorInputStream.java:308)
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.readBackReference(AbstractLZ77CompressorInputStream.java:291)
> at
> org.apache.commons.compress.compressors.lz4.BlockLZ4CompressorInputStream.read(BlockLZ4CompressorInputStream.java:83)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.readOnce(FramedLZ4CompressorInputStream.java:328)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.read(FramedLZ4CompressorInputStream.java:145)
> at java.io.InputStream.read(InputStream.java:101)
> {noformat}
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.tryToCopy(AbstractLZ77CompressorInputStream.java:304)
> at
> org.apache.commons.compress.compressors.lz77support.AbstractLZ77CompressorInputStream.readBackReference(AbstractLZ77CompressorInputStream.java:291)
> at
> org.apache.commons.compress.compressors.lz4.BlockLZ4CompressorInputStream.read(BlockLZ4CompressorInputStream.java:83)
> at
> org.apache.commons.compress.compressors.lz4.BlockLZ4CompressorInputStream.read(BlockLZ4CompressorInputStream.java:75)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.readOnce(FramedLZ4CompressorInputStream.java:328)
> at
> org.apache.commons.compress.compressors.lz4.FramedLZ4CompressorInputStream.read(FramedLZ4CompressorInputStream.java:145)
> at java.io.InputStream.read(InputStream.java:101)
> {noformat}
> The inputs were automatically generated by fuzzing, by repeatedly mutating
> random bytes in a well-formed file.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-470) ParallelScatterZipCreator leaks temporary files (and maybe more)
[
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-470:
Labels: zip (was: )
> ParallelScatterZipCreator leaks temporary files (and maybe more)
>
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
>
> As indicated by
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679878#comment-16679878
> COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-475) 7z archive entry class does not override the equals method
[ https://issues.apache.org/jira/browse/COMPRESS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-475: Labels: 7z (was: ) > 7z archive entry class does not override the equals method > -- > > Key: COMPRESS-475 > URL: https://issues.apache.org/jira/browse/COMPRESS-475 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.18 >Reporter: Robin Schimpf >Priority: Major > Labels: 7z > Fix For: 1.19 > > > I have all archive entries of a 7z saved in a list and try to only get the > content of a specific file. Comparing the archive entries with equals will > always return false because the equals method is not overridden. > I will compare the name of the archive entry for now. > While looking through all archive entry implementations I noticed that the > Arj entry also does not override the equals method. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-469) java.io.IOException: Error detected parsing the header on un-archiving. Archive untars fine in BSDTar and JTar
[
https://issues.apache.org/jira/browse/COMPRESS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-469:
Component/s: Archivers
> java.io.IOException: Error detected parsing the header on un-archiving.
> Archive untars fine in BSDTar and JTar
> --
>
> Key: COMPRESS-469
> URL: https://issues.apache.org/jira/browse/COMPRESS-469
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
> Environment: Java version: 1.8.0_192, vendor: Oracle Corporation,
> runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
>
> bsdtar 2.8.3 - libarchive 2.8.3
>Reporter: Kirk Hardy
>Priority: Major
> Fix For: 1.19
>
> Attachments: compress-bug-POC.tar.gz
>
>
> Using TarArchiveInputStream to parse this tar archive results in a
> `java.io.IOException: Error detected parsing the header`
> `Caused by: java.lang.IllegalArgumentException: Invalid byte 78 at offset 8
> in 'NaN\{NUL}' len=12`
>
> The `NaN\{NUL}` value is indeed found in the tar archive at the point
> that TarArchiveInputStream finds it and errors, but both BSDTar from a bash
> shell and JTar from a Java environment handle the archive fine, including the
> file with the malformed header. My commons-compress code is:
> {code:java}
> private static List unTar(final File inputFile, final File outputDir)
> throws FileNotFoundException, IOException, ArchiveException {
> System.out.println(String.format("Untaring %s to dir %s.",
> inputFile.getAbsolutePath(), outputDir.getAbsolutePath()));
> final List untaredFiles = new LinkedList();
> final InputStream is = new FileInputStream(inputFile);
> final TarArchiveInputStream debInputStream = (TarArchiveInputStream) new
> ArchiveStreamFactory().createArchiveInputStream("tar", is);
> TarArchiveEntry entry = null;
> while ((entry = (TarArchiveEntry) debInputStream.getNextEntry()) != null)
> {
> final File outputFile = new File(outputDir, entry.getName());
> if (entry.isDirectory()) {
> System.out.println(String.format("Attempting to write output
> directory %s.", outputFile.getAbsolutePath()));
> if (!outputFile.exists()) {
> System.out
> .println(String.format("Attempting to create output directory
> %s.", outputFile.getAbsolutePath()));
> if (!outputFile.mkdirs()) {
> throw new IllegalStateException(
> String.format("Couldn't create directory %s.",
> outputFile.getAbsolutePath()));
> }
> }
> }
> else {
> System.out.println(String.format("Creating output file %s.",
> outputFile.getAbsolutePath()));
> final OutputStream outputFileStream = new
> FileOutputStream(outputFile);
> IOUtils.copy(debInputStream, outputFileStream);
> outputFileStream.close();
> }
> untaredFiles.add(outputFile);
> }
> debInputStream.close();
> return untaredFiles;
> }
> {code}
> [^compress-bug-POC.tar.gz]
> I've attached an archive of my proof-of-concept code that un-archives the
> problem archive using JTar, then attempts to un-archive it using
> commons-compress. The problem archive is included. Unfortunately I wasn't
> involved in the creation of the problem archive, it was downloaded from NPM
> last year, so I don't have any details about the archival process that caused
> the malformed header.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-475) 7z archive entry class does not override the equals method
[ https://issues.apache.org/jira/browse/COMPRESS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-475: Component/s: Archivers > 7z archive entry class does not override the equals method > -- > > Key: COMPRESS-475 > URL: https://issues.apache.org/jira/browse/COMPRESS-475 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.18 >Reporter: Robin Schimpf >Priority: Major > Fix For: 1.19 > > > I have all archive entries of a 7z saved in a list and try to only get the > content of a specific file. Comparing the archive entries with equals will > always return false because the equals method is not overridden. > I will compare the name of the archive entry for now. > While looking through all archive entry implementations I noticed that the > Arj entry also does not override the equals method. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-469) java.io.IOException: Error detected parsing the header on un-archiving. Archive untars fine in BSDTar and JTar
[
https://issues.apache.org/jira/browse/COMPRESS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-469:
Labels: tar (was: )
> java.io.IOException: Error detected parsing the header on un-archiving.
> Archive untars fine in BSDTar and JTar
> --
>
> Key: COMPRESS-469
> URL: https://issues.apache.org/jira/browse/COMPRESS-469
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
> Environment: Java version: 1.8.0_192, vendor: Oracle Corporation,
> runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14", arch: "x86_64", family: "mac"
>
> bsdtar 2.8.3 - libarchive 2.8.3
>Reporter: Kirk Hardy
>Priority: Major
> Labels: tar
> Fix For: 1.19
>
> Attachments: compress-bug-POC.tar.gz
>
>
> Using TarArchiveInputStream to parse this tar archive results in a
> `java.io.IOException: Error detected parsing the header`
> `Caused by: java.lang.IllegalArgumentException: Invalid byte 78 at offset 8
> in 'NaN\{NUL}' len=12`
>
> The `NaN\{NUL}` value is indeed found in the tar archive at the point
> that TarArchiveInputStream finds it and errors, but both BSDTar from a bash
> shell and JTar from a Java environment handle the archive fine, including the
> file with the malformed header. My commons-compress code is:
> {code:java}
> private static List unTar(final File inputFile, final File outputDir)
> throws FileNotFoundException, IOException, ArchiveException {
> System.out.println(String.format("Untaring %s to dir %s.",
> inputFile.getAbsolutePath(), outputDir.getAbsolutePath()));
> final List untaredFiles = new LinkedList();
> final InputStream is = new FileInputStream(inputFile);
> final TarArchiveInputStream debInputStream = (TarArchiveInputStream) new
> ArchiveStreamFactory().createArchiveInputStream("tar", is);
> TarArchiveEntry entry = null;
> while ((entry = (TarArchiveEntry) debInputStream.getNextEntry()) != null)
> {
> final File outputFile = new File(outputDir, entry.getName());
> if (entry.isDirectory()) {
> System.out.println(String.format("Attempting to write output
> directory %s.", outputFile.getAbsolutePath()));
> if (!outputFile.exists()) {
> System.out
> .println(String.format("Attempting to create output directory
> %s.", outputFile.getAbsolutePath()));
> if (!outputFile.mkdirs()) {
> throw new IllegalStateException(
> String.format("Couldn't create directory %s.",
> outputFile.getAbsolutePath()));
> }
> }
> }
> else {
> System.out.println(String.format("Creating output file %s.",
> outputFile.getAbsolutePath()));
> final OutputStream outputFileStream = new
> FileOutputStream(outputFile);
> IOUtils.copy(debInputStream, outputFileStream);
> outputFileStream.close();
> }
> untaredFiles.add(outputFile);
> }
> debInputStream.close();
> return untaredFiles;
> }
> {code}
> [^compress-bug-POC.tar.gz]
> I've attached an archive of my proof-of-concept code that un-archives the
> problem archive using JTar, then attempts to un-archive it using
> commons-compress. The problem archive is included. Unfortunately I wasn't
> involved in the creation of the problem archive, it was downloaded from NPM
> last year, so I don't have any details about the archival process that caused
> the malformed header.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-466:
Labels: zip (was: )
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-464) Improve preparation of the compressed ARJ archives support
[
https://issues.apache.org/jira/browse/COMPRESS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-464:
Labels: arj (was: )
> Improve preparation of the compressed ARJ archives support
> --
>
> Key: COMPRESS-464
> URL: https://issues.apache.org/jira/browse/COMPRESS-464
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.19
>Reporter: Rostislav Krasny
>Priority: Trivial
> Labels: arj
> Fix For: 1.19
>
> Attachments: patch.txt
>
>
> Add a few more constants of the ARJ archive and update references to the ARJ
> file format documentation. This improves the preparation of the compressed
> ARJ archive support that will be implemented sometime in a future.
> See attached {{patch.txt}} file.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-464) Improve preparation of the compressed ARJ archives support
[
https://issues.apache.org/jira/browse/COMPRESS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-464:
Component/s: Archivers
> Improve preparation of the compressed ARJ archives support
> --
>
> Key: COMPRESS-464
> URL: https://issues.apache.org/jira/browse/COMPRESS-464
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.19
>Reporter: Rostislav Krasny
>Priority: Trivial
> Fix For: 1.19
>
> Attachments: patch.txt
>
>
> Add a few more constants of the ARJ archive and update references to the ARJ
> file format documentation. This improves the preparation of the compressed
> ARJ archive support that will be implemented sometime in a future.
> See attached {{patch.txt}} file.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-466) Opening of a very large zip file is extremely slow compared to java.util.zip.ZipFile
[
https://issues.apache.org/jira/browse/COMPRESS-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-466:
Component/s: (was: Compressors)
Archivers
> Opening of a very large zip file is extremely slow compared to
> java.util.zip.ZipFile
>
>
> Key: COMPRESS-466
> URL: https://issues.apache.org/jira/browse/COMPRESS-466
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.18
> Environment: Tested both on Linux and OSX 10.13.6.
>Reporter: Jakob Sultan Ericsson
>Priority: Major
> Fix For: 1.19
>
>
> We have a quite large zip file 35 gb and try to open this with ZipFile.
> {code:java}
> try (ZipFile zf = new ZipFile(new File("35gb.zip"))) {
> System.out.println("File opened..." + (System.currentTimeMillis()
> - start));
> }
> {code}
> This code takes about 300 000 - 400 000 ms (5-6 minutes).
> If I run this with JDK-builtin java.util.zip.ZipFile, same code takes 300 ms
> (less than a second).
> I'm not totally sure what it is the problem but I did some debugging and
> basically all time is spent in
> {code:java}
> private void resolveLocalFileHeaderData(final Map NameAndComment> entriesWithoutUTF8Flag)
> {code}
> Anything that can be done to improve this?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-485) Reproducible Builds: keep entries order when gathering ScatterZipOutputStream content in ParallelScatterZipCreator
[ https://issues.apache.org/jira/browse/COMPRESS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-485: Labels: zip (was: ) > Reproducible Builds: keep entries order when gathering ScatterZipOutputStream > content in ParallelScatterZipCreator > -- > > Key: COMPRESS-485 > URL: https://issues.apache.org/jira/browse/COMPRESS-485 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Hervé Boutemy >Priority: Major > Labels: zip > Fix For: 1.19 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > currently, zip files created using ParallelScatterZipCreator have random > order. > This is causing issues when trying to do Reproducible Builds with Maven > MNG-6276 > Studying ParallelScatterZipCreator, entries are kept sorted in memory in > futures list: instead of writing each full scatter in sequence, iterating > over futures should permit to write each zip entry in original order, without > changing the API or any performance of the gathering process -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-487) PKWARE DCL Implode support (ZIP compression method 10)
[
https://issues.apache.org/jira/browse/COMPRESS-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-487:
Labels: zip (was: )
> PKWARE DCL Implode support (ZIP compression method 10)
> --
>
> Key: COMPRESS-487
> URL: https://issues.apache.org/jira/browse/COMPRESS-487
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers, Compressors
>Reporter: Emmanuel Bourg
>Priority: Minor
> Labels: zip
> Attachments: dclimplode-ascii-1024.zip, dclimplode-ascii-2048.zip,
> dclimplode-ascii-4096.zip, dclimplode-binary-1024.zip,
> dclimplode-binary-2048.zip, dclimplode-binary-4096.zip
>
>
> Commons Compress doesn't yet support the implode compression algorithm
> implemented in the PKWARE Data Compression Library (DCL). This algorithm can
> be used in ZIP files (using the compression method 10, which differs from the
> other implode compression method 6 already supported). It's also used in some
> old file formats like dBASE/xBase and game files from the 90's (.mpq).
> ZIP files using this compression method can be created with recent versions
> of the [PKWARE ZIP Compression Utility|https://www.pkware.com/pkzip]. The
> syntax looks like this:
> {{pkzipc -add -dclimplode=ascii,4096 test.zip *.txt}}
> The format is documented here:
> https://groups.google.com/forum/#!msg/comp.compression/M5P064or93o/W1ca1-ad6kgJ
> and here is the implementation in zlib:
> https://github.com/madler/zlib/blob/master/contrib/blast/blast.c
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-482) ZipArchiveInputStream's "data descriptor for stored entries" feature doesn't work if the data descriptor doesn't contain a signature
[
https://issues.apache.org/jira/browse/COMPRESS-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-482:
Labels: zip (was: )
> ZipArchiveInputStream's "data descriptor for stored entries" feature doesn't
> work if the data descriptor doesn't contain a signature
>
>
> Key: COMPRESS-482
> URL: https://issues.apache.org/jira/browse/COMPRESS-482
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Assignee: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
>
> In the first branch of the next block from {{bufferContainSignature}}
> {code:java}
> if ((buf.array()[i + 2] == LFH[2] && buf.array()[i + 3] ==
> LFH[3])
> || (buf.array()[i] == CFH[2] && buf.array()[i + 3] ==
> CFH[3])) {
> // found a LFH or CFH:
> readTooMuch = offset + lastRead - i - expectedDDLen;
> done = true;
> }
> else if (buf.array()[i + 2] == DD[2] && buf.array()[i + 3] ==
> DD[3]) {
> // found DD:
> readTooMuch = offset + lastRead - i;
> done = true;
> }
> {code}
> {{readTooMuch}} should probably add {{expectedDDLen}} rather than subtract
> it. It leaves the DD inside of the read stream for the last stored entry
> rather than positioning the stream in front of it. Unfortunately we don't
> seem to have a single unit test that would execute the branch.
> Also the current implementation of {{bufferContainSignature}} will stop when
> a local file header is found even before enough data for a data descriptor
> has been read at all. In COMPRESS-480 it will detect the very first local
> file header in the embedded XPI file at offset 0 even though there must be
> twelve bytes of data descriptor before the first candidate.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-480) Unexpected record signature when using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-480:
Component/s: Archivers
> Unexpected record signature when using ZipArchiveInputStream
>
>
> Key: COMPRESS-480
> URL: https://issues.apache.org/jira/browse/COMPRESS-480
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Luboš Doležel
>Priority: Major
>
> I'm trying to use ZipArchiveInputStream for reading a [Firefox
> APK|https://www.dropbox.com/s/u725t87sew5b539/firefox-65-0-1.apk?dl=0]. I
> cannot use ZipFile (although the example below _could_) and I'm aware of the
> limitations.
> The file makes use of "stored entries with data descriptor".
> This code example triggers an exception:
> {code}
> ZipArchiveInputStream zis = new ZipArchiveInputStream(new
> FileInputStream(apk), "UTF-8", false, true);
> while (zis.getNextZipEntry() != null);
> {code}
> This is the exception reported: {{Unexpected record signature: 0X4374756F}}
> Could it possibly be fixed or is this ZIP file impossible to read using
> ZipArchiveInputStream?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-480) Unexpected record signature when using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-480:
Labels: zip (was: )
> Unexpected record signature when using ZipArchiveInputStream
>
>
> Key: COMPRESS-480
> URL: https://issues.apache.org/jira/browse/COMPRESS-480
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Luboš Doležel
>Priority: Major
> Labels: zip
>
> I'm trying to use ZipArchiveInputStream for reading a [Firefox
> APK|https://www.dropbox.com/s/u725t87sew5b539/firefox-65-0-1.apk?dl=0]. I
> cannot use ZipFile (although the example below _could_) and I'm aware of the
> limitations.
> The file makes use of "stored entries with data descriptor".
> This code example triggers an exception:
> {code}
> ZipArchiveInputStream zis = new ZipArchiveInputStream(new
> FileInputStream(apk), "UTF-8", false, true);
> while (zis.getNextZipEntry() != null);
> {code}
> This is the exception reported: {{Unexpected record signature: 0X4374756F}}
> Could it possibly be fixed or is this ZIP file impossible to read using
> ZipArchiveInputStream?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-474) xlsx zip64 compatibility
[ https://issues.apache.org/jira/browse/COMPRESS-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-474: Labels: zip (was: ) > xlsx zip64 compatibility > > > Key: COMPRESS-474 > URL: https://issues.apache.org/jira/browse/COMPRESS-474 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.19 >Reporter: Krzysztof Rzymkowski >Priority: Major > Labels: zip > > Excel's xlsx files are generally zip archives. But Excel has a very specific > and strict ZIP64 implementation. > Connected Apache POI issue: > [https://bz.apache.org/bugzilla/show_bug.cgi?id=57342 > ]My blog post with all the details: > [https://rzymek.github.io/post/excel-zip64/] > My observations on Excel requirements: > # If file size is > 4gb, then zip spec version 4.5 must be set in Local > Header File > # In streaming creation the zero file sizes must be in 32 field, not in > LHF's ZIP64 extra field data. > # ZIP64 extra field in Central Directory must not include > relativeHeaderOffset. Only size or size and compressed size > # ZIP64 Central Directory is not supported > I did verify these in a +prototype+ repository at > [https://github.com/rzymek/commons-compress/pull/1/files]. This is just a > playground where I've tested the changes to verify that Excel opens the > generated file. > Test project: https://github.com/rzymek/xlsx-compress64-test > > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-479:
Component/s: Archivers
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-477) Support for splitted zip files
[
https://issues.apache.org/jira/browse/COMPRESS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-477:
Labels: zip (was: )
> Support for splitted zip files
> --
>
> Key: COMPRESS-477
> URL: https://issues.apache.org/jira/browse/COMPRESS-477
> Project: Commons Compress
> Issue Type: New Feature
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Luis Filipe Nassif
>Priority: Major
> Labels: zip
>
> It would be very useful to support splitted zip files. I've read
> [https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT] and understood
> that simply concatenating the segments and removing the split signature
> 0x08074b50 from first segment would be sufficient, but it is not that simple
> because compress fails with exception below:
> {code}
> Caused by: java.util.zip.ZipException: archive's ZIP64 end of central
> directory locator is corrupt.
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory64(ZipFile.java:924)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:901)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:621)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:295)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:280)
> ~[commons-compress-1.18.jar:1.18]
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:236)
> ~[commons-compress-1.18.jar:1.18]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-479:
Assignee: Stefan Bodewig
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Assignee: Stefan Bodewig
>Priority: Major
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-479) Unable to extract Zip with unknown UniCode path extra data version
[
https://issues.apache.org/jira/browse/COMPRESS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-479:
Labels: zip (was: )
> Unable to extract Zip with unknown UniCode path extra data version
> --
>
> Key: COMPRESS-479
> URL: https://issues.apache.org/jira/browse/COMPRESS-479
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Robin Schimpf
>Assignee: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
> Attachments: unicode-test10509149899131946592.zip
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following exception is thrown when the version of the UniCode path extra
> data version is not 1. 7-Zip and Windows Explorer will extract the attached
> file. The version in the file was changed via a Hex editor to provoke the
> error.
> {code:java}
> java.lang.RuntimeException: Error parsing extra fields for entry:
> %U20AC_for_Dollar.txt - Unsupported version [116] for UniCode path extra data.
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:626)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:315)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:408)
> at
> org.apache.commons.compress.archivers.zip.UTF8ZipFilesTest.testZipFileReadsUnicodeFields(UTF8ZipFilesTest.java:186)
> ...
> Caused by: java.util.zip.ZipException: Unsupported version [116] for UniCode
> path extra data.
> at
> org.apache.commons.compress.archivers.zip.AbstractUnicodeExtraField.parseFromLocalFileData(AbstractUnicodeExtraField.java:172)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:180)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:620)
> {code}
> As I understand the specification in Section 4.6.8 and 4.6.9 when the version
> is unknown the information shoule be ignored.
> Changes MAY NOT be backward compatible so this extra field *SHOULD NOT be
> used if the version is not recognized*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[ https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-489: Labels: zip (was: ) > Reading Central File Header and Archive extra data record, with out Skipping > > > Key: COMPRESS-489 > URL: https://issues.apache.org/jira/browse/COMPRESS-489 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Anvesh Mora >Assignee: Stefan Bodewig >Priority: Minor > Labels: zip > Attachments: image-2019-06-10-17-02-33-972.png > > > - Some Zip files store extra data in CFH and AED. Right now it seems that we > are skipping the meta data instead of making it available to consumer and > choose to use it or not. > - It might sound small change but right now this kind of flexibility is not > allowed with inheritance, due to lot of private and package access specifiers > ( NOT open for extension) > - If extension is not something we are looking, providing a method which > allows to store CFH and AED data based on a flag, should make it work. > > I had similar requirement in my current development and I had to re-write the > component and use below code-snippet in > ZipArchieveInputStream#getNextZipEntry method: > !image-2019-06-10-17-02-33-972.png! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[ https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-489: Component/s: Archivers > Reading Central File Header and Archive extra data record, with out Skipping > > > Key: COMPRESS-489 > URL: https://issues.apache.org/jira/browse/COMPRESS-489 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Anvesh Mora >Priority: Minor > Attachments: image-2019-06-10-17-02-33-972.png > > > - Some Zip files store extra data in CFH and AED. Right now it seems that we > are skipping the meta data instead of making it available to consumer and > choose to use it or not. > - It might sound small change but right now this kind of flexibility is not > allowed with inheritance, due to lot of private and package access specifiers > ( NOT open for extension) > - If extension is not something we are looking, providing a method which > allows to store CFH and AED data based on a flag, should make it work. > > I had similar requirement in my current development and I had to re-write the > component and use below code-snippet in > ZipArchieveInputStream#getNextZipEntry method: > !image-2019-06-10-17-02-33-972.png! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[ https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-489: Assignee: Stefan Bodewig > Reading Central File Header and Archive extra data record, with out Skipping > > > Key: COMPRESS-489 > URL: https://issues.apache.org/jira/browse/COMPRESS-489 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Anvesh Mora >Assignee: Stefan Bodewig >Priority: Minor > Attachments: image-2019-06-10-17-02-33-972.png > > > - Some Zip files store extra data in CFH and AED. Right now it seems that we > are skipping the meta data instead of making it available to consumer and > choose to use it or not. > - It might sound small change but right now this kind of flexibility is not > allowed with inheritance, due to lot of private and package access specifiers > ( NOT open for extension) > - If extension is not something we are looking, providing a method which > allows to store CFH and AED data based on a flag, should make it work. > > I had similar requirement in my current development and I had to re-write the > component and use below code-snippet in > ZipArchieveInputStream#getNextZipEntry method: > !image-2019-06-10-17-02-33-972.png! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-483) ZipArchiveInputStream's "data descriptor for stored entries" feature should check the size for consistency
[
https://issues.apache.org/jira/browse/COMPRESS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-483:
Fix Version/s: 1.19
> ZipArchiveInputStream's "data descriptor for stored entries" feature should
> check the size for consistency
> --
>
> Key: COMPRESS-483
> URL: https://issues.apache.org/jira/browse/COMPRESS-483
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
> Labels: zip
> Fix For: 1.19
>
>
> If {{ZipArchiveInputStream}} thinks it has found a data descriptor for a
> stored entry it should verify the size just read actually matches the size of
> the entry read so far and throw an exception if there is a mismatch.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (COMPRESS-489) Reading Central File Header and Archive extra data record, with out Skipping
[
https://issues.apache.org/jira/browse/COMPRESS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903985#comment-16903985
]
Stefan Bodewig commented on COMPRESS-489:
-
Is there anything that you would need when using {{ZipFile}} that is not
provided right now?
> Reading Central File Header and Archive extra data record, with out Skipping
>
>
> Key: COMPRESS-489
> URL: https://issues.apache.org/jira/browse/COMPRESS-489
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Anvesh Mora
>Priority: Minor
> Attachments: image-2019-06-10-17-02-33-972.png
>
>
> - Some Zip files store extra data in CFH and AED. Right now it seems that we
> are skipping the meta data instead of making it available to consumer and
> choose to use it or not.
> - It might sound small change but right now this kind of flexibility is not
> allowed with inheritance, due to lot of private and package access specifiers
> ( NOT open for extension)
> - If extension is not something we are looking, providing a method which
> allows to store CFH and AED data based on a flag, should make it work.
>
> I had similar requirement in my current development and I had to re-write the
> component and use below code-snippet in
> ZipArchieveInputStream#getNextZipEntry method:
> !image-2019-06-10-17-02-33-972.png!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (COMPRESS-480) Unexpected record signature when using ZipArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-480.
-
Resolution: Won't Fix
{{ZipArchiveInputStream}} really doesn't stand any chance of reading this
archive. Using {{ZipFile}} is the only approach that can work.
With COMPRESS-483 we stand a chance of detecting the situation where the stord
entry with data descriptor is a ZIP archive and throw a more useful exception.
I will use this opportunity to stress the problem in our docs even stronger
than we've done so far.
> Unexpected record signature when using ZipArchiveInputStream
>
>
> Key: COMPRESS-480
> URL: https://issues.apache.org/jira/browse/COMPRESS-480
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
>Reporter: Luboš Doležel
>Priority: Major
>
> I'm trying to use ZipArchiveInputStream for reading a [Firefox
> APK|https://www.dropbox.com/s/u725t87sew5b539/firefox-65-0-1.apk?dl=0]. I
> cannot use ZipFile (although the example below _could_) and I'm aware of the
> limitations.
> The file makes use of "stored entries with data descriptor".
> This code example triggers an exception:
> {code}
> ZipArchiveInputStream zis = new ZipArchiveInputStream(new
> FileInputStream(apk), "UTF-8", false, true);
> while (zis.getNextZipEntry() != null);
> {code}
> This is the exception reported: {{Unexpected record signature: 0X4374756F}}
> Could it possibly be fixed or is this ZIP file impossible to read using
> ZipArchiveInputStream?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (IO-617) Add class CloseShieldWriter. #83
[ https://issues.apache.org/jira/browse/IO-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed IO-617. --- Resolution: Fixed Fix Version/s: 2.7 In git master. > Add class CloseShieldWriter. #83 > > > Key: IO-617 > URL: https://issues.apache.org/jira/browse/IO-617 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.7 > > > Add class CloseShieldWriter. #83. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (COMPRESS-483) ZipArchiveInputStream's "data descriptor for stored entries" feature should check the size for consistency
[
https://issues.apache.org/jira/browse/COMPRESS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-483:
Description: If {{ZipArchiveInputStream}} thinks it has found a data
descriptor for a stored entry it should verify the size just read actually
matches the size of the entry read so far and throw an exception if there is a
mismatch. (was: If {{ZipArchiveInputStream}} thinks it has found a data
descriptor for a stored entry it should very the size just read actually
matches the size of the entry read so far and throw an exception if there is a
mismatch.)
> ZipArchiveInputStream's "data descriptor for stored entries" feature should
> check the size for consistency
> --
>
> Key: COMPRESS-483
> URL: https://issues.apache.org/jira/browse/COMPRESS-483
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
> Labels: zip
>
> If {{ZipArchiveInputStream}} thinks it has found a data descriptor for a
> stored entry it should verify the size just read actually matches the size of
> the entry read so far and throw an exception if there is a mismatch.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [commons-io] asfgit closed pull request #83: Added ClosedWriter and CloseShieldWriter.
asfgit closed pull request #83: Added ClosedWriter and CloseShieldWriter. URL: https://github.com/apache/commons-io/pull/83 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IO-617) Add class CloseShieldWriter. #83
Gary Gregory created IO-617: --- Summary: Add class CloseShieldWriter. #83 Key: IO-617 URL: https://issues.apache.org/jira/browse/IO-617 Project: Commons IO Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add class CloseShieldWriter. #83. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (COMPRESS-486) Expander causes "Cleaning up unclosed ZipFile" to be written to stderr
[
https://issues.apache.org/jira/browse/COMPRESS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-486.
-
Resolution: Fixed
Fix Version/s: 1.19
Fixed in master for the cases where Expander/Archiver own the stream/channel
and added a callback mechanism for the remaining cases that allows the calling
code to close the resources.
> Expander causes "Cleaning up unclosed ZipFile" to be written to stderr
> --
>
> Key: COMPRESS-486
> URL: https://issues.apache.org/jira/browse/COMPRESS-486
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.18
> Environment: Java 1.8, Windows 10, IntelliJ 2018.2.7
>Reporter: Jordan Piscitelli
>Priority: Minor
> Fix For: 1.19
>
>
> Using the Expander, I found that it will create a zip file that is not closed
> which results in an error message being written to std-err when garbage
> collection (and finalization) occurs.
> I believe it is [line 140 of the
> Expander|https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L140]
> as it creates a zip file that does not appear to be closed.
> {code:java}
> 140: expand(new ZipFile(archive), targetDirectory);{code}
> I have created a test that demonstrates the behavior. It runs
> Expander.expand(file, file) followed by garbage collection and finalize, and
> passes if stderr was not written to.
> Currently the test fails as "Cleaning up unclosed ZipFile for archive unknown
> archive" is written to stderr.
> {code:java}
> import java.io.ByteArrayOutputStream;
> import java.io.File;
> import java.io.FileOutputStream;
> import java.io.IOException;
> import java.io.OutputStream;
> import java.io.PrintStream;
> import java.nio.charset.StandardCharsets;
> import org.apache.commons.compress.archivers.ArchiveException;
> import org.apache.commons.compress.archivers.ArchiveOutputStream;
> import org.apache.commons.compress.archivers.ArchiveStreamFactory;
> import org.apache.commons.compress.archivers.examples.Expander;
> import org.codehaus.plexus.util.StringUtils;
> import org.junit.jupiter.api.Test;
> import org.springframework.util.Assert;
> public class ExpanderCloseTest {
> @Test
> public void testExpanderClosesZipFile() {
> final ByteArrayOutputStream errOutputStream = new
> ByteArrayOutputStream();
> try {
> final File sourceArchiveFile = createSampleZip();
> final File targetExpansionDirectory =
> File.createTempFile("dest.zip", null);
> try (PrintStream ps = new PrintStream(errOutputStream, true,
> "UTF-8")) {
> System.setErr(ps);
> Expander expander = new Expander();
> expander.expand(sourceArchiveFile, targetExpansionDirectory);
> System.gc();
> System.runFinalization();
> }
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
> String stderr = new String(errOutputStream.toByteArray(),
> StandardCharsets.UTF_8);
> Assert.isTrue(StringUtils.isBlank(stderr), "Nothing should have been
> written to stderr, but this was: " + stderr);
> }
> private File createSampleZip() throws IOException, ArchiveException {
> final File sourceArchiveFile = File.createTempFile("example.zip",
> null);
> OutputStream archiveStream = new FileOutputStream(sourceArchiveFile);
> ArchiveOutputStream archive = new
> ArchiveStreamFactory().createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> archiveStream);
> archive.finish();
> archiveStream.close();
> return sourceArchiveFile;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Closed] (IO-616) Add class AppendableWriter. #87.
[ https://issues.apache.org/jira/browse/IO-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed IO-616. --- Resolution: Fixed Fix Version/s: 2.7 In git master. > Add class AppendableWriter. #87. > > > Key: IO-616 > URL: https://issues.apache.org/jira/browse/IO-616 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.7 > > > Add class AppendableWriter. #87. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (IO-615) Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, IOExceptionList, IOIndexedException.
[ https://issues.apache.org/jira/browse/IO-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed IO-615. --- Resolution: Fixed Fix Version/s: 2.7 In git master. > Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, > IOExceptionList, IOIndexedException. > -- > > Key: IO-615 > URL: https://issues.apache.org/jira/browse/IO-615 > Project: Commons IO > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.7 > > > Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, > IOExceptionList, IOIndexedException. > Inspired by https://github.com/apache/commons-io/pull/88 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IO-616) Add class AppendableWriter. #87.
Gary Gregory created IO-616: --- Summary: Add class AppendableWriter. #87. Key: IO-616 URL: https://issues.apache.org/jira/browse/IO-616 Project: Commons IO Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add class AppendableWriter. #87. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [commons-io] garydgregory merged pull request #87: Added AppendableWriter.
garydgregory merged pull request #87: Added AppendableWriter. URL: https://github.com/apache/commons-io/pull/87 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-io] asfgit closed pull request #88: Added TeeWriter.
asfgit closed pull request #88: Added TeeWriter. URL: https://github.com/apache/commons-io/pull/88 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IO-615) Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, IOExceptionList, IOIndexedException.
Gary Gregory created IO-615: --- Summary: Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, IOExceptionList, IOIndexedException. Key: IO-615 URL: https://issues.apache.org/jira/browse/IO-615 Project: Commons IO Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Add classes TeeWriter, FilterCollectionWriter, ProxyCollectionWriter, IOExceptionList, IOIndexedException. Inspired by https://github.com/apache/commons-io/pull/88 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (LOGGING-167) [Java-9][JPMS] automatic module cannot be used with jlink: commons.logging
[ https://issues.apache.org/jira/browse/LOGGING-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903840#comment-16903840 ] Michael Osipov commented on LOGGING-167: Use the SLF4J replacement, it has the proper module name: org.apache.commons.logging > [Java-9][JPMS] automatic module cannot be used with jlink: commons.logging > -- > > Key: LOGGING-167 > URL: https://issues.apache.org/jira/browse/LOGGING-167 > Project: Commons Logging > Issue Type: Bug >Affects Versions: 1.2 > Environment: MacOS > Oracle Linux > >Reporter: Denis Makogon >Priority: Major > > I'm building a modular project and one of my modules uses apache http client, > so, subsequently, my code depends on commons-logging and when I'm building > the jlink-ed JRE, I'm seeing this: > ``` > [ERROR] Error: automatic module cannot be used with jlink: commons.logging > from > file:home/root/.m2/repository/commons-logging/commons-logging/1.2/commons-logging-1.2.jar > ``` > meaning, that commons-logging and few other modules (bits of http package) > are not java modules. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MATH-1495) Calling NaturalRanking#rank() on an array of all NaNs throws a misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
[
https://issues.apache.org/jira/browse/MATH-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903818#comment-16903818
]
Gilles commented on MATH-1495:
--
bq. ArrayIndexOutOfBoundsException
I agree that it should not be the expected outcome.
Is the behaviour the same in the development version?
> Calling NaturalRanking#rank() on an array of all NaNs throws a misleading
> ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED
>
>
> Key: MATH-1495
> URL: https://issues.apache.org/jira/browse/MATH-1495
> Project: Commons Math
> Issue Type: Bug
>Reporter: Akash Srivastava
>Priority: Major
>
> Consider the following code:
> {code:java}
> import org.apache.commons.math3.stat.ranking.NaNStrategy;
> import org.apache.commons.math3.stat.ranking.NaturalRanking;
> import org.apache.commons.math3.stat.ranking.TiesStrategy;
> class AllNaNException{
> public NaturalRanking naturalranking;
> public double[] AllNaNArray(){
> naturalranking = new NaturalRanking(NaNStrategy.REMOVED,
> TiesStrategy.AVERAGE);
> double[] x = {Double.NaN, Double.NaN};
> double[] y = naturalranking.rank(x);
> return y;
> }
> public static void main(String[] args) {
> AllNaNException a = new AllNaNException();
> double[] res = a.bug();
> System.out.println(res[0] + "," + res[1]);
> }
> }
> {code}
> Compiled it by: javac -cp /usr/share/java/commons-math3-3.6.1.jar tryit.java
> Executed it by: java -cp /usr/share/java/commons-math3-3.6.1.jar:. tryit
>
> Output:
> {code:java}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.commons.math3.stat.ranking.NaturalRanking.rank(NaturalRanking.java:231)
> at tryit.bug(tryit.java:9)
> at tryit.main(tryit.java:14)
> {code}
>
> Currently, calling NaturalRanking#rank() on an array of all NaNs throws a
> misleading ArrayIndexOutOfBoundsException when the NanStrategy is REMOVED. I
> am unsure what outcome the user should expect in code like the test case I
> have provided below. Can you shed some light on this? I am happy to write a
> pull request once I know what fix would be best. I think throwing an
> IllegalArgumentException or returning an empty array would be more apt in
> this case.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-99) Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903809#comment-16903809
]
Gilles commented on NUMBERS-99:
---
bq. simply not requiring the stored denominator to be positive, but this would
probably break a lot of functionality
Internal functionality? That should be fixable; otherwise, "simply" is not the
right word ;-)
As far as external is concerned, there is no requirement to stick with a
decision implicitly made when those classes were in "Commons Math", especially
if they entail a bug.
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
>
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (NUMBERS-123) "BigFraction(double)" is unnecessary
[
https://issues.apache.org/jira/browse/NUMBERS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-123.
Resolution: Done
> "BigFraction(double)" is unnecessary
>
>
> Key: NUMBERS-123
> URL: https://issues.apache.org/jira/browse/NUMBERS-123
> Project: Commons Numbers
> Issue Type: Improvement
> Components: fraction
>Reporter: Gilles
>Assignee: Gilles
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: NUMBERS-123__Javadoc.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Constructor {{BigFraction(double value)}} is only called from the
> {{from(double value)}} method.
> Actually, this constructor is misleading as it is indeed primarily a
> conversion from which appropriate {{numerator}} and {{denominator}} fields
> are computed; those could be set by
> the "direct" constructor {{BigFraction(BigInteger num, BigInteger den)}}.
> Moreover, the private field {{ZERO}} goes through this conversion code
> whereas it could constructed "directly", e.g. using {{of(0)}}. Similarly for
> field {{ONE}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-133) Speed up Primes.nextPrime(int)
[
https://issues.apache.org/jira/browse/NUMBERS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903804#comment-16903804
]
Gilles commented on NUMBERS-133:
The other advantage of MathJaX/LaTeX (vs Unicode characters?) is that some
(text-based) softwares (e.g. "git diff") do not show the glyphs and display
rather "cryptic" sequences of characters. Which makes it fairly annoying to
review...
> Speed up Primes.nextPrime(int)
> --
>
> Key: NUMBERS-133
> URL: https://issues.apache.org/jira/browse/NUMBERS-133
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{Primes.nextPrime(int)}} can use the same algorithm to skip
> multiples of certain primes as {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} uses, instead of hard-coding the alternating increment of
> the trial candidate into a loop.
> Also, if the argument of the method is smaller than or equal to the 512th
> prime number, the method can just infer the next higher prime number directly
> from the array {{SmallPrimes.PRIMES}} without performing any calculations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (NUMBERS-133) Speed up Primes.nextPrime(int)
[
https://issues.apache.org/jira/browse/NUMBERS-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903803#comment-16903803
]
Gilles commented on NUMBERS-133:
The rule of thumb would to use MathJaX for any formula that would make it
easier to read (rendered or not).
The bar is quite low since even exponents and indices read better in LaTeX:
{noformat}
N_i^k
{noformat}
vs
{noformat}
Ni^k
{noformat}
bq. documentation of private or package-private elements? \[...\] IDEs
generally don't render the MathJax \[...\]
Even so, it's clearer IMO. :-)
When referring to code elements (e.g. variable names), I generally use the
Javadoc "@code" tag:
{code}
/**
* @throws IllegalArgumentException if {@code x <= 0}.
*/
{code}
and the LaTeX syntax for mostly everything else (math-related).
Perhaps we should also provide rendered Javadoc for internal development, where
the private elements are shown (?).
> Speed up Primes.nextPrime(int)
> --
>
> Key: NUMBERS-133
> URL: https://issues.apache.org/jira/browse/NUMBERS-133
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Affects Versions: 1.0
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The method {{Primes.nextPrime(int)}} can use the same algorithm to skip
> multiples of certain primes as {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} uses, instead of hard-coding the alternating increment of
> the trial candidate into a loop.
> Also, if the argument of the method is smaller than or equal to the 512th
> prime number, the method can just infer the next higher prime number directly
> from the array {{SmallPrimes.PRIMES}} without performing any calculations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (LANG-1472) SystemUtils.getHostName()获取系统hostname为null
[
https://issues.apache.org/jira/browse/LANG-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903690#comment-16903690
]
Michael Osipov commented on LANG-1472:
--
Please share your environment: {{$ env}}.
> SystemUtils.getHostName()获取系统hostname为null
> --
>
> Key: LANG-1472
> URL: https://issues.apache.org/jira/browse/LANG-1472
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: * 操作系统：阿里云提供的Ubuntu 16.04
> root@iZwz99ibpdra8w3j3jcbw7Z:~# hostname
> iZwz99ibpdra8w3j3jcbw7Z
> root@iZwz99ibpdra8w3j3jcbw7Z:~# echo $HOSTNAME
> iZwz99ibpdra8w3j3jcbw7Z
> * 语言：Java 8
> root@iZwz99ibpdra8w3j3jcbw7Z:~# java -version
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
>Reporter: wangrubao
>Priority: Critical
> Attachments: error.png
>
>
> SpringBoot 项目获取系统 hostname 为 null 导致 java.lang.NullPointerException 。
> 部分代码：
>private static Long getDataCenterId(){
> int[] ints = StringUtils.toCodePoints(SystemUtils.getHostName());
> int sums = 0;
> for (int i: ints) {
> sums += i;
> }
> return (long)(sums % 32);
> }
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
