[GitHub] commons-lang pull request: Add method to DiffBuilder to allow appe...
GitHub user NickManley opened a pull request: https://github.com/apache/commons-lang/pull/122 Add method to DiffBuilder to allow appending from a DiffResult. You can merge this pull request into a Git repository by running: $ git pull https://github.com/NickManley/commons-lang appendDiffs Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/122.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #122 commit 9d67c28999caa4a654f607c29fb5cc363e3487c4 Author: Nick Manley Date: 2016-01-24T07:27:30Z Add method to DiffBuilder to allow appending from a DiffResult. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request: DiffBuilder: Add null check on fieldNam...
GitHub user NickManley opened a pull request: https://github.com/apache/commons-lang/pull/121 DiffBuilder: Add null check on fieldName when appending Object or Object[] The other append methods throw an IllegalArgumentException if fieldName is null. So, I added it here as well. You can merge this pull request into a Git repository by running: $ git pull https://github.com/NickManley/commons-lang nullcheck Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/121.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #121 commit bec30ff404ea52b822ee47d9e6271b789697c19c Author: Nick Manley Date: 2016-01-24T05:35:23Z Add null check on fieldName when appending Object or Object[]. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (CHAIN-106) JavaDoc report contains JavaDocs of cookbook examples
[ https://issues.apache.org/jira/browse/CHAIN-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15114018#comment-15114018 ] Brent Worden commented on CHAIN-106: This appears to have been addressed. The latest JavaDocs report do not contain the the cookbook packages. http://commons.apache.org/proper/commons-chain/apidocs/index.html > JavaDoc report contains JavaDocs of cookbook examples > - > > Key: CHAIN-106 > URL: https://issues.apache.org/jira/browse/CHAIN-106 > Project: Commons Chain > Issue Type: Sub-task > Components: Build >Affects Versions: 2.0 >Reporter: Benedikt Ritter > Labels: site > Fix For: 2.0 > > > The cookbook examples are not really part of the API, there is no reason to > include the JavaDoc of the cookbook in the JavaDoc report of the main site. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-331) Some non TAR files are recognized by ArchiveStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113966#comment-15113966
]
Jeremy Gustie commented on COMPRESS-331:
There are a number of garbage values in the first entry (the one whose
{{isCheckSumOK}} is called): perhaps in addition to the current
{{isCheckSumOK}} check the archive stream factory can also sanity check
something like the device number.
>From my understanding of the comments, another possibility might be only
>allowing the {{storedSum > unsignedSum}} check if the magic is blank. The
>magic would need to be captured like stored sum is now for this additional
>check (it looks like the magic offset is already a constant).
Here are the values on the entry I am seeing from the {{ic_secure.png}} (note
that I zapped a bunch of Gremlins in the name to avoid problems) just in case
some one has some better ideas for how to quickly identify obviously bad
entries:
|{{checkSumOK}}|{{true}}|
|{{devMajor}}|{{2134088}}|
|{{devMinor}}|{{2363913}}|
|{{file}}|{{null}}|
|{{groupId}}|{{2134088}}|
|{{groupName}}|{{"01101101101101101101101101101101"}}|
|{{isExtended}}|{{false}}|
|{{linkFlag}}|{{48}}|
|{{linkName}}|{{"1101101101101101101101101101101101101101101101101101101101101101101101101101101101101101101101101101"}}|
|{{magic}}|{{"101101"}}|
|{{mode}}|{{2363913}}|
|{{modTime}}|{{9682587720}}|
|{{name}}|{{"01101101101101...blah...blah...blah...PNG...blah...blah...blah...110110110110110110110110110110110"}}|
|{{realSize}}|{{0}}|
|{{size}}|{{9682587720}}|
|{{userId}}|{{295489}}|
|{{userName}}|{{"11011011011011011011011011011011"}}|
|{{version}}|{{"10"}}|
> Some non TAR files are recognized by ArchiveStreamFactory
> -
>
> Key: COMPRESS-331
> URL: https://issues.apache.org/jira/browse/COMPRESS-331
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.10
>Reporter: Jeremy Gustie
> Attachments: ic_secure.png
>
>
> I ran into a case where a PNG file is being recognized as TAR because
> {{TarUtils.verifyCheckSum}} reports it as having a valid checksum (in this
> case the code thinks the stored checksum is 36936, unsigned is 31155 and
> signed is 19635). Because the stored checksum value is larger then the
> unsigned checksum it is treated as a valid TAR.
> I haven't spent enough time digging into the problem to see if there is a
> good alternative to the existing check that doesn't have false positives like
> this PNG file (which, if anyone is interested comes from an Android download).
> Also, I noticed a minor thing in the code: the comment in
> {{TarUtils.verifyCheckSum}} has the wrong bug number listed (it says 177
> instead of 117).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COMPRESS-331) Some non TAR files are recognized by ArchiveStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeremy Gustie updated COMPRESS-331:
---
Attachment: ic_secure.png
> Some non TAR files are recognized by ArchiveStreamFactory
> -
>
> Key: COMPRESS-331
> URL: https://issues.apache.org/jira/browse/COMPRESS-331
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.10
>Reporter: Jeremy Gustie
> Attachments: ic_secure.png
>
>
> I ran into a case where a PNG file is being recognized as TAR because
> {{TarUtils.verifyCheckSum}} reports it as having a valid checksum (in this
> case the code thinks the stored checksum is 36936, unsigned is 31155 and
> signed is 19635). Because the stored checksum value is larger then the
> unsigned checksum it is treated as a valid TAR.
> I haven't spent enough time digging into the problem to see if there is a
> good alternative to the existing check that doesn't have false positives like
> this PNG file (which, if anyone is interested comes from an Android download).
> Also, I noticed a minor thing in the code: the comment in
> {{TarUtils.verifyCheckSum}} has the wrong bug number listed (it says 177
> instead of 117).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (COMPRESS-331) Some non TAR files are recognized by ArchiveStreamFactory
Jeremy Gustie created COMPRESS-331:
--
Summary: Some non TAR files are recognized by ArchiveStreamFactory
Key: COMPRESS-331
URL: https://issues.apache.org/jira/browse/COMPRESS-331
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.10
Reporter: Jeremy Gustie
I ran into a case where a PNG file is being recognized as TAR because
{{TarUtils.verifyCheckSum}} reports it as having a valid checksum (in this case
the code thinks the stored checksum is 36936, unsigned is 31155 and signed is
19635). Because the stored checksum value is larger then the unsigned checksum
it is treated as a valid TAR.
I haven't spent enough time digging into the problem to see if there is a good
alternative to the existing check that doesn't have false positives like this
PNG file (which, if anyone is interested comes from an Android download).
Also, I noticed a minor thing in the code: the comment in
{{TarUtils.verifyCheckSum}} has the wrong bug number listed (it says 177
instead of 117).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMPRESS-330) Tar UnArchive Fails when archive contains directory sizes which are non-zero.
[ https://issues.apache.org/jira/browse/COMPRESS-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113760#comment-15113760 ] Stefan Bodewig commented on COMPRESS-330: - Thanks. Your patch looks backwards (removing your changes), but that's no problem. But I'm afraid you forgot to add COMPRESS-330.tar > Tar UnArchive Fails when archive contains directory sizes which are non-zero. > - > > Key: COMPRESS-330 > URL: https://issues.apache.org/jira/browse/COMPRESS-330 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.10 > Environment: Java 1.8 >Reporter: Dye357 >Priority: Minor > Attachments: Compress-330.patch > > > Tar UnArchive Fails when archive contains directory sizes which are non-zero. > I recently came across a set of files which failed to extract with > commons-compress but I was able to successfully extract the files with GNU > tar. > The problem is TarArchiveInputStream.java gets the size of each entry in a > tar archive to determine how many bytes to read ahead. Directories are always > sized 0 bytes, however its technically possible a tar archive contains a size > for a directory. This causes the Input Stream to loose it's place and > eventually results in an exception being thrown. > I was able to implement a proof-of-concept fix by checking if an entity is a > directory and setting the directory size to 0. (A directory with Files in a > Tar Archive still has a size of 0 as the directory itself does not have size > in the archive.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-291) decompress .7z archive very very slow
[
https://issues.apache.org/jira/browse/COMPRESS-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113757#comment-15113757
]
Stefan Bodewig commented on COMPRESS-291:
-
Thanks for the link - I'm far from being an expert in code optimization at all.
Ar first glance it seems to be {{Unsafe}} or Java9. But is seems as if
consequently using {{ByteBuffer}} could help even for Java7. Requiring Java7 in
future versions of Commons Compress 1.x should be an option by now.
And thank you for confirming a slowdown in the bzip2 case as well, of course
bzip2 is also implemented in plain Java. We may want to compare a Deflate or
even a Copy decoder in order to see whether {{SevenZFile}} or the
implementation of the compression algorithm is to blame.
> decompress .7z archive very very slow
> -
>
> Key: COMPRESS-291
> URL: https://issues.apache.org/jira/browse/COMPRESS-291
> Project: Commons Compress
> Issue Type: Improvement
> Components: Compressors
>Affects Versions: 1.9
> Environment: Windows 7 x64, jdk1.7.0_21 x64
>Reporter: Robert Jansen
>Priority: Minor
>
> I have 7z archives with one large image and many small files. The following
> code decompresses to a directory and returns the largest file. It is
> glacially slow and not usable for GB size files:
> public File unSevenZipToDir(File sevenZipFile, File outputDir) {
>
> File imgFile = null;
> // Make sure output dir exists
> outputDir.mkdirs();
> if (outputDir.exists()) {
>
> //FileInputStream stream;
> try {
>
> FileOutputStream output = null;
> SevenZFile f7z = new SevenZFile(sevenZipFile);
> SevenZArchiveEntry entry;
> long maxSize = 0;
> while ((entry = f7z.getNextEntry()) != null) {
> if (entry != null) {
> String s = entry.getName();
> if (s != null) {
> long sz =
> entry.getSize();
>
> if (sz > 0) {
> int count;
> byte data[] =
> new byte[4096];
>
> String
> outFileName = outputDir.getPath() + "/"
>
> + new File(entry.getName()).getName();
>
>
>
>
>
>
>
>
>
>
>
>
>
> File outFile =
> new File(outFileName);
>
> // Extract only
> if it does not already exist
> if
> (outFile.exists() == false) {
>
> System.out.println("Extracting " + s + " => size = " + sz);
>
>
>
>
> FileOutputStream fos = new FileOutputStream(
>
> outFile);
>
>
>
> BufferedOutputStream dest = new Buf
