[jira] [Commented] (COMPRESS-189) ZipArchiveInputStream may read 0 bytes when reading from a nested Zip file
[
https://issues.apache.org/jira/browse/COMPRESS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541346#comment-13541346
]
Stefan Bodewig commented on COMPRESS-189:
-
Hmm, I'll look around the website in time before the next release to asses
whether it really is suitable to be included. Maybe there is an easy way to
create a similar testcase ourselves.
As for COMPRESS-205, I've seen it - it will take some time until I get to it.
ZipArchiveInputStream may read 0 bytes when reading from a nested Zip file
--
Key: COMPRESS-189
URL: https://issues.apache.org/jira/browse/COMPRESS-189
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.4.1
Environment: JDK 1.6 64-bit, Windows 7
Reporter: Daniel Lowe
Priority: Blocker
Fix For: 1.5
When the following code is run an error Underlying input stream returned
zero bytes is produced. If the commented line is uncommented it can be seen
that the ZipArchiveInputStream returned 0 bytes. This only happens the first
time read is called, subsequent calls work as expected i.e. the following
code actually works correctly with that line uncommented!
The zip file used to produce this behavious is available at
http://wwmm.ch.cam.ac.uk/~dl387/test.ZIP
If this is not the correct way of processing a zip file of zip files please
let me know. Also I believe whilst ZipFile can iterate over entries fast due
to being able to look at the master table whilst ZipArchiveInputStream
cannot. Is there anyway of instantiating a ZipFile from a zip file inside
another zip file without first extracting the nested zip file?
ZipFile zipFile = new ZipFile(C:/test.ZIP);
for (EnumerationZipArchiveEntry iterator = zipFile.getEntries();
iterator.hasMoreElements(); ) {
ZipArchiveEntry entry = iterator.nextElement();
InputStream is = new BufferedInputStream(zipFile.getInputStream(entry));
ZipArchiveInputStream zipInput = new ZipArchiveInputStream(is);
ZipArchiveEntry innerEntry;
while ((innerEntry = zipInput.getNextZipEntry()) != null){
if (innerEntry.getName().endsWith(XML)){
//zipInput.read();
System.out.println(IOUtils.toString(zipInput));
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-205) Unit tests can fail when path to project is non-trivial (fix in description)
[
https://issues.apache.org/jira/browse/COMPRESS-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541348#comment-13541348
]
Stefan Bodewig commented on COMPRESS-205:
-
Some of our tests will need real File instances (at least those of ZipFile and
some Pack200 ones), but we could make thse tests conditional or use JUnit4
assumptions. I'll look into it a bit later.
Unit tests can fail when path to project is non-trivial (fix in description)
Key: COMPRESS-205
URL: https://issues.apache.org/jira/browse/COMPRESS-205
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.5
Reporter: Daniel Lowe
Priority: Minor
Attachments: COMPRESS-205.patch
return factory.createCompressorInputStream(new BufferedInputStream(new
FileInputStream(new File(rsc.getFile();
can fail to find the files for testing e.g.
/root/.jenkins/jobs/Commons%20Compress/workspace/target/test-classes/test.txt
(No such file or directory)
This can be fixed by simply opening the stream from the URL:
private CompressorInputStream getStreamFor(String resource)
throws CompressorException, IOException {
final URL rsc = classLoader.getResource(resource);
assertNotNull(Could not find resource +resource,rsc);
return factory.createCompressorInputStream(
new BufferedInputStream(rsc.openStream()));
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-206) TarArchiveOutputStream sometimes writes garbage beyond the end of the archive
[ https://issues.apache.org/jira/browse/COMPRESS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541349#comment-13541349 ] Stefan Bodewig commented on COMPRESS-206: - I didn't mean to imply this was a duplicate of 202 or anything like that, but rather that your patch provides one alternative to fix COMPRESS-202 beyond just documenting the behavior. We'll need to discuss on the dev list how we want to solve it, but for the sake of getting more opinions I'll wait a few days until people are back from their holiday time-outs. Given tar record reading may be willing to consume non-tar inputs, we may need to be more careful there. I'll need to look into the tar dialect documentations a bit more to see what we might need to accept as part of the archive once the first EOF-record has been found. TarArchiveOutputStream sometimes writes garbage beyond the end of the archive - Key: COMPRESS-206 URL: https://issues.apache.org/jira/browse/COMPRESS-206 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.0, 1.4.1 Environment: Linux x86 Reporter: Peter De Maeyer Fix For: 1.5 Attachments: COMPRESS-206.patch For some combinations of file lengths, the archive created by TarArchiveOutputStream writes garbage beyond the end of the TAR stream. TarArchiveInputStream can still read the stream without problems, but it does not read beyond the garbage. This is problematic for my use case because I write a checksum _after_ the TAR content. If I then try to read the checksum back, I read garbage instead. Functional impact: * TarArchiveInputStream is asymmetrical with respect to TarArchiveOutputStream, in the sense that TarArchiveInputStream does not read everything that was written by TarArchiveOutputStream. * The content is unnecessarily large. The garbage is totally unnecessarily large: ~10K overhead compared to Linux command-line tar. This symptom is remarkably similar to #COMPRESS-81, which is supposedly fixed since 1.1. Except for the fact that this issue still exists... I've tested this with 1.0 and 1.4.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-208) Add support for ZIP archives with PK00PK signature
[
https://issues.apache.org/jira/browse/COMPRESS-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541354#comment-13541354
]
Stefan Bodewig commented on COMPRESS-208:
-
You are right and all we'd need to do is prepending PK00 to an existing good
archive.
Add support for ZIP archives with PK00PK signature
--
Key: COMPRESS-208
URL: https://issues.apache.org/jira/browse/COMPRESS-208
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.4.1
Reporter: Dmitry Katsubo
Attachments: EP02797238.zip
ZIP archive with PK00PK signature is not recognized as ZIP archive by
{{ArchiveStreamFactory.createArchiveInputStream()}}. Header hexdump:
{code}
00: 50 4B 30 30 50 4B 03 04 │ 14 00 00 00 08 00 48 7D PK00PK♥♦¶ ◘
H}
10: F4 36 04 E0 50 2C 04 27 │ 01 00 E2 3F 10 00 37 00 Ї6♦рP,♦'☺ т?► 7
20: 00 00 4E 39 32 30 34 35 │ 20 53 45 52 20 4A 52 4EN92045 SER
JRN
30: 20 72 65 76 69 73 65 64 │ 20 73 65 71 20 6C 69 73 revised seq
lis
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-362) IOUtils.contentEquals(inputStream1, inputStream2) returns false if inputStream1 == inputStream2, should return true
Matthew Madson created IO-362:
-
Summary: IOUtils.contentEquals(inputStream1, inputStream2) returns
false if inputStream1 == inputStream2, should return true
Key: IO-362
URL: https://issues.apache.org/jira/browse/IO-362
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.4
Reporter: Matthew Madson
The fix should be relatively simple, just add an identity check to the
beginning of the method:
if(is1 == is2) {
return true;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-926) Refactor the o.a.c.m.optim package
Gilles created MATH-926: --- Summary: Refactor the o.a.c.m.optim package Key: MATH-926 URL: https://issues.apache.org/jira/browse/MATH-926 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Gilles Assignee: Gilles Fix For: 4.0 The optim package should only refer to the strict definition of an optimization problem: minimizing a cost function. The non-linear least-squares optimizers should be considered as fitting algorithms and moved to the o.a.c.m.fitting package. In the AbstractLeastSquaresOptimizer class, the handling of weights should be dropped because # it obscures the algorithm's primary purpose, and # this feature could be implemented independently (by the user, or in a wrapper). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
