[GitHub] [commons-io] garydgregory merged pull request #455: Bump moditect-maven-plugin from 1.0.0.RC3 to 1.0.0.Final
garydgregory merged PR #455: URL: https://github.com/apache/commons-io/pull/455 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory merged pull request #127: Bump Saxon-HE from 12.1 to 12.2
garydgregory merged PR #127: URL: https://github.com/apache/commons-scxml/pull/127 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (DAEMON-459) Restart only works once (regression)
[
https://issues.apache.org/jira/browse/DAEMON-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-459.
Fix Version/s: 1.3.4
Resolution: Fixed
Thanks for the test case.
> Restart only works once (regression)
>
>
> Key: DAEMON-459
> URL: https://issues.apache.org/jira/browse/DAEMON-459
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.3
>Reporter: Klaus Malorny
>Priority: Major
> Fix For: 1.3.4
>
> Attachments: ApacheDaemonBug.zip
>
>
> For certain functions, especially code updates, we rely on the ability to
> restart the child process. This seems to work only once. On the subsequent
> attempt, the child process hangs.
> I tracked down the problem and found out that the problem is within the
> {{jsvc-unix.c}} file. The {{main_reload}} function is called to send the
> signal to itself, but this does not happen. In the first restart, the
> {{controlled}} variable holds the value of 0. This works by chance, as the
> signal is sent to the parent, which sends it back to the child. In the second
> attempt, the variable holds the PID of the previous child, thus the signal is
> sent to a no longer existing process.
> The {{controlled}} variable is used both by the parent and the child process.
> In earlier versions of the file, the child process determines its own PID by
> using the {{getpid}} system function. This call has been – likely
> accidentally – removed in version 1.3.3 or earlier. Thus, the variable
> contains the parent's value before the fork which has created the child.
> The solution is simple: in the function {{{}child{}}}, add
> {{ controlled = getpid ();}}
> between the {{sigaction}} calls and the {{log_debug ("Waiting for a signal to
> be delivered")}} call (line 913 in my copy of the file), i.e.
> {{ ...}}
> {{ memset(&act, '\0', sizeof(act));}}
> {{ act.sa_handler = handler;}}
> {{ sigemptyset(&act.sa_mask);}}
> {{ act.sa_flags = SA_RESTART | SA_NOCLDSTOP;}}
> {{ sigaction(SIGHUP, &act, NULL);}}
> {{ sigaction(SIGUSR1, &act, NULL);}}
> {{ sigaction(SIGUSR2, &act, NULL);}}
> {{ sigaction(SIGTERM, &act, NULL);}}
> {{ sigaction(SIGINT, &act, NULL);}}
> {{ *controlled = getpid ();*}}
> {{ log_debug("Waiting for a signal to be delivered");}}
> {{ create_tmp_file(args);}}
> {{ while (!stopping) {}}
> {{ ...}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719457#comment-17719457
]
Mark Thomas commented on DAEMON-457:
I have followed the provided steps and am unable to recreate the issue on a
fully patched Windows 2019 server. I also tried running the same command
multiple times (~20) and generated a really long list of Java 9 options in the
registry without any error being reported.
It looks very much like there is something else about the environment on the
affected machines that is triggering the issue.
More detail about the issue when it happens (Does it happen for any option? Is
it related to the length of the added value? Is it related to the total length
of the new value? etc.) may help us narrow down where the problem may be.
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9
> --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
> {code}
> Above command fails with below crash in EventViewer:
> Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp:
> 0x637e7ca5
> Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
> 0x65420ea4
> Exception code: 0xc374
> Fault offset: 0x000fa979
> Faulting process id: 0x298
> Faulting application start time: 0x01d967f65ac00dce
> Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
> Faulting package full name:
> Please let me know if you need any more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JEXL-397) Dynamic proxy should not require specific permission
[
https://issues.apache.org/jira/browse/JEXL-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-397.
Resolution: Fixed
https://github.com/apache/commons-jexl/commit/46854b60a75fba8ec96066fae6051e38c6fe1245
> Dynamic proxy should not require specific permission
>
>
> Key: JEXL-397
> URL: https://issues.apache.org/jira/browse/JEXL-397
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4
>
>
> With the default restricted permissions, dynamic proxies can not be
> introspected since they extend java.lang.reflect.Proxy whose package is
> denied.
> A workaround is to explicitly allow them as in:
> {code:java}
> JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
> @Override public boolean allow(Class clazz) {
> return Proxy.isProxyClass(clazz) || super.allow(clazz);
> }
> };
> {code}
> This workaround should not be necessary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-396) Add explicit Java module descriptor
[ https://issues.apache.org/jira/browse/JEXL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-396: --- Assignee: Henri Biestro > Add explicit Java module descriptor > --- > > Key: JEXL-396 > URL: https://issues.apache.org/jira/browse/JEXL-396 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.3 >Reporter: Andres Almiray >Assignee: Henri Biestro >Priority: Major > > Follow up from a > [topic|https://lists.apache.org/thread/kxcwqyx026rhhx4v8q8bkbljj7lw8c32] > started at the mailing list. > Henri suggested using the ModiTect plugin guarded by a profile with JDK > activation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated COMPRESS-643:
-
Fix Version/s: (was: 2.0)
> ZipArchiveInputStream.getCompressedCount is not calculated properly
> ---
>
> Key: COMPRESS-643
> URL: https://issues.apache.org/jira/browse/COMPRESS-643
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.21, 1.23.0
>Reporter: Zsolt F
>Priority: Major
> Attachments: test.zip
>
>
> h2. Context
> During iterating over the zip entries by using ZipArchiveInputStream the
> provided
> getCompressedCount and getUncompressedCount methods do not return the
> correct values when the stream content is not fully read.Demo
> The zip file used in the code snippets attached to the jira.
> *Good behaviour*
> Executing the follow code working as expected:
>
> {code:java}
> final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
> FileInputStream("test.zip"));
> while (true)
> {
> final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
> if (null == nextZipEntry)
> {
> break;
> }
> //reading all the content
> stream.readAllBytes();
> System.out.println(String.format("[%s] compressed size: [%d] uncompressed
> size: [%d], calculated ratio: [%.2f]",
> nextZipEntry.getName(),
> stream.getCompressedCount(),
> stream.getUncompressedCount(),
> (double) stream.getCompressedCount() /
> stream.getUncompressedCount()));
> } {code}
> Output:
> {code:java}
> [first.xml] compressed size: [475830] uncompressed size: [16239665],
> calculated ratio: [0.03]
> [last.xml] compressed size: [2221] uncompressed size: [45481], calculated
> ratio: [0.05] {code}
> *Bad behaviour*
> The next code snippet doesn't read the second entry fully only 16 bytes, and
> in this case the calculated values are wrong.
> {code:java}
> final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
> FileInputStream("test.zip"));
> while (true)
> {
> final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
> if (null == nextZipEntry)
> {
> break;
> }
> //reading fully only the last entry
> if ("first.xml".equals(nextZipEntry.getName()))
> {
> stream.readAllBytes();
> }
> else
> {
> stream.readNBytes(16);
> }
> System.out.println(String.format("[%s] compressed size: [%d] uncompressed
> size: [%d], calculated ratio: [%.2f]",
> nextZipEntry.getName(),
> stream.getCompressedCount(),
> stream.getUncompressedCount(),
> (double) stream.getCompressedCount() /
> stream.getUncompressedCount()));
> } {code}
> Output:
> {code:java}
> [first.xml] compressed size: [475830] uncompressed size: [16239665],
> calculated ratio: [0.03]
> [last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
> [5.06] {code}
> The calculated ratio is wrong for the last.xml due to the provided compressed
> size and uncompressed size.
> This issue is also reproducible in case of iterating over the zip entries
> and read the content only for the last entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JEXL-397) Dynamic proxy should not require specific permission
[
https://issues.apache.org/jira/browse/JEXL-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-397:
---
Description:
With the default restricted permissions, dynamic proxies can not be
introspected since they extend java.lang.reflect.Proxy whose package is denied.
A workaround is to explicitly allow them as in:
{code:java}
JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
@Override public boolean allow(Class clazz) {
return Proxy.isProxyClass(clazz) || super.allow(clazz);
}
};
{code}
This workaround should not be necessary.
was:
With the default restricted permissions, dynamic proxies can not be
introspected since they extend java.lang.reflect.Proxy whose package is denied.
The workaround is to explicitly allow them as in:
{code:java}
JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
@Override public boolean allow(Class clazz) {
return Proxy.isProxyClass(clazz) || super.allow(clazz);
}
};
{code}
> Dynamic proxy should not require specific permission
>
>
> Key: JEXL-397
> URL: https://issues.apache.org/jira/browse/JEXL-397
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.4
>
>
> With the default restricted permissions, dynamic proxies can not be
> introspected since they extend java.lang.reflect.Proxy whose package is
> denied.
> A workaround is to explicitly allow them as in:
> {code:java}
> JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
> @Override public boolean allow(Class clazz) {
> return Proxy.isProxyClass(clazz) || super.allow(clazz);
> }
> };
> {code}
> This workaround should not be necessary.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JEXL-397) Dynamic proxy should not require specific permission
Henri Biestro created JEXL-397:
--
Summary: Dynamic proxy should not require specific permission
Key: JEXL-397
URL: https://issues.apache.org/jira/browse/JEXL-397
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.3
Reporter: Henri Biestro
Assignee: Henri Biestro
Fix For: 3.4
With the default restricted permissions, dynamic proxies can not be
introspected since they extend java.lang.reflect.Proxy whose package is denied.
The workaround is to explicitly allow them as in:
{code:java}
JexlPermissions p = new JexlPermissions.Delegate(JexlPermissions.RESTRICTED) {
@Override public boolean allow(Class clazz) {
return Proxy.isProxyClass(clazz) || super.allow(clazz);
}
};
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong for the last.xml due to the provided compressed
size and uncompressed size.
This issue is also reproducible in case of iterating over the zip entries and
read the content only for the last entry.
was:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calc
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is also reproducible in case of iterating over the zip entries and
read the content only for the last entry.
was:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], cal
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is also reproducible in case of iterating over the zip entries and
read the content only for the last entry.
was:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665]
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
was:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed s
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading fully only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
was:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompres
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMPRESS-643:
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
was:
{code:java}
{code}
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compres
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zsolt F updated COMPRESS-643:
-
Description:
{code:java}
{code}
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
was:
{code:java}
// code placeholder
{code}
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:
[jira] [Created] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
Zsolt F created COMPRESS-643:
Summary: ZipArchiveInputStream.getCompressedCount is not
calculated properly
Key: COMPRESS-643
URL: https://issues.apache.org/jira/browse/COMPRESS-643
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.23.0, 1.21
Reporter: Zsolt F
Fix For: 2.0
Attachments: test.zip
{code:java}
// code placeholder
{code}
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
