You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Aleksey Shipilev (JIRA)" <ji...@apache.org> on 2010/07/05 14:27:51 UTC
[jira] Created: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
ZipArchiveInputStream fails to uncompress stream generated by InfoZip
---------------------------------------------------------------------
Key: COMPRESS-116
URL: https://issues.apache.org/jira/browse/COMPRESS-116
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.0
Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
Reporter: Aleksey Shipilev
Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
Steps to reproduce:
1. Download sample-*.zip. These two files were generated with Info-ZIP.
sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
3. Observe the following output:
Reading sample-ordinary.zip
name=temp/, size=0
Read 0 bytes
name=temp/test.100, size=100
Read 100 bytes
name=temp/test.10000, size=10000
Read 10000 bytes
name=temp/test.10000.zip, size=10170
Read 10170 bytes
name=temp/test.1M, size=1048576
Read 1048576 bytes
name=temp/test.10M, size=10485760
Read 10485760 bytes
Reading sample-streaming.zip
name=temp/, size=0
Read 0 bytes
name=temp/test.100, size=-1
Read 100 bytes
name=temp/test.10000, size=-1
Read 10000 bytes
name=temp/test.10M, size=-1
Read 10485760 bytes
name=temp/test.10000.zip, size=-1
Read 0 bytes
Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
No exceptions are thrown, the implementation thinks the stream is actually over.
Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885232#action_12885232 ]
Stefan Bodewig commented on COMPRESS-116:
-----------------------------------------
The piece you've missed from my comment was "enabling data descriptors for STORED entries explicitly" 8-)
Data Descriptors, STORED entries and streaming are a dangerous combination and you must explicitly
enable it with a new constructor argument in order to use it. If you don't enable it you get the exception
(rather than a truncated entry like in 1.0).
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885221#action_12885221 ]
Aleksey Shipilev commented on COMPRESS-116:
-------------------------------------------
Hi Stefan, thanks for the pointer!
This is with today's trunk:
------------------- cut ---------------------
$ java -cp ~/trunks/commons-compress/target/commons-compress-1.1-SNAPSHOT.jar:. TestInfoZip
Reading sample-ordinary.zip
name=temp/, size=0
Read 0 bytes
name=temp/test.100, size=100
Read 100 bytes
name=temp/test.10000, size=10000
Read 10000 bytes
name=temp/test.10000.zip, size=10170
Read 10170 bytes
name=temp/test.1M, size=1048576
Read 1048576 bytes
name=temp/test.10M, size=10485760
Read 10485760 bytes
Reading sample-streaming.zip
name=temp/, size=0
Read 0 bytes
name=temp/test.100, size=-1
Read 100 bytes
name=temp/test.10000, size=-1
Read 10000 bytes
name=temp/test.10M, size=-1
Read 10485760 bytes
name=temp/test.10000.zip, size=-1
Exception in thread "main" org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException: unsupported feature data descriptor used in entry temp/test.10000.zip
at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:245)
at java.io.InputStream.read(InputStream.java:85)
at TestInfoZip.read(TestInfoZip.java:27)
at TestInfoZip.main(TestInfoZip.java:13)
------------------- cut ---------------------
Is this intended behaviour?
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885237#action_12885237 ]
Aleksey Shipilev commented on COMPRESS-116:
-------------------------------------------
Right, I see now. The proposed workaround seem to be very dangerous.
Let me think about it.
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stefan Bodewig resolved COMPRESS-116.
-------------------------------------
Fix Version/s: 1.1
Resolution: Duplicate
Yep, I've tested your test archive against trunk, enabling data descriptors for STORED entries explicitly, and it extracts just fine.
Duplicate of COMPRESS-103
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885209#action_12885209 ]
Stefan Bodewig commented on COMPRESS-116:
-----------------------------------------
I think this is a duplicate of COMPRESS-103 which is fixed in trunk.
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Shipilev updated COMPRESS-116:
--------------------------------------
Attachment: sample-ordinary.zip
sample-streaming.zip
TestInfoZip.java
Sample ZIP files and test.
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Stefan Bodewig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885233#action_12885233 ]
Stefan Bodewig commented on COMPRESS-116:
-----------------------------------------
Background: http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/site/xdoc/zip.xml?p2=%2Fcommons%2Fproper%2Fcompress%2Ftrunk%2Fsrc%2Fsite%2Fxdoc%2Fzip.xml&p1=%2Fcommons%2Fproper%2Fcompress%2Ftrunk%2Fsrc%2Fsite%2Fxdoc%2Fzip.xml&r1=925271&r2=925270&view=diff&pathrev=925271
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COMPRESS-116) ZipArchiveInputStream fails to
uncompress stream generated by InfoZip
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885229#action_12885229 ]
Aleksey Shipilev commented on COMPRESS-116:
-------------------------------------------
Stafan, I'm puzzled. You had tested against the fresh trunk, with these two archives attached to this issue, and had not see the exception?
Because I'm seem to be doing precisely the same, and exception is there.
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COMPRESS-116) ZipArchiveInputStream
fails to uncompress stream generated by InfoZip
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COMPRESS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885229#action_12885229 ]
Aleksey Shipilev edited comment on COMPRESS-116 at 7/5/10 9:16 AM:
-------------------------------------------------------------------
Stafan, I'm puzzled. You had tested against the fresh trunk, with these two archives attached to this issue, and had not see the exception?
Because I seem to be doing precisely the same, and exception is there.
was (Author: aleksey.shipilev):
Stafan, I'm puzzled. You had tested against the fresh trunk, with these two archives attached to this issue, and had not see the exception?
Because I'm seem to be doing precisely the same, and exception is there.
> ZipArchiveInputStream fails to uncompress stream generated by InfoZip
> ---------------------------------------------------------------------
>
> Key: COMPRESS-116
> URL: https://issues.apache.org/jira/browse/COMPRESS-116
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.0
> Environment: Linux, Info-ZIP 3.0 (July 5th 2008), Compress 1.0
> Reporter: Aleksey Shipilev
> Fix For: 1.1
>
> Attachments: sample-ordinary.zip, sample-streaming.zip, TestInfoZip.java
>
>
> Current Compress implementation silently fails to uncompress streaming zip coming from Info-ZIP.
> Should this behaviour proven to be adherent to spec, some sort of Exception should be thrown instead of silencing the error.
> Steps to reproduce:
> 1. Download sample-*.zip. These two files were generated with Info-ZIP.
> sample-ordinary.zip was generated with "zip -r sample-ordinary.zip temp/".
> sample-streaming.zip was generated with "zip -fd -r - temp/ > sample-streaming.zip". Note that "-fd" flag forces data descriptors in stream. This is enabled automatically if the pipe sink is not the file, e.g. if you call it as "zip -r - temp/ | pv > sample-streaming.zip". For convenience, I did it by forcing descriptors via flag.
> 2. Download, compile and run TestInfoZip.java, placing Compress on classpath.
> 3. Observe the following output:
> Reading sample-ordinary.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=100
> Read 100 bytes
> name=temp/test.10000, size=10000
> Read 10000 bytes
> name=temp/test.10000.zip, size=10170
> Read 10170 bytes
> name=temp/test.1M, size=1048576
> Read 1048576 bytes
> name=temp/test.10M, size=10485760
> Read 10485760 bytes
> Reading sample-streaming.zip
> name=temp/, size=0
> Read 0 bytes
> name=temp/test.100, size=-1
> Read 100 bytes
> name=temp/test.10000, size=-1
> Read 10000 bytes
> name=temp/test.10M, size=-1
> Read 10485760 bytes
> name=temp/test.10000.zip, size=-1
> Read 0 bytes
> Note that sample-ordinary is read OK, while streaming version had failed read on one of the entries.
> No exceptions are thrown, the implementation thinks the stream is actually over.
> Another finding: this reproduces perfectly when there's at least one STORED entry in the stream.
> Generating Info-ZIP files with maximum compression (e.g. all entries are DEFLATED) works around this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.