Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 13 Dec 2016 13:19:58 +0000 (UTC)
From: "Alexandre Sieira (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13027782.1481634124000.508787.1481635198394@Atlassian.JIRA>
In-Reply-To: <JIRA.13027782.1481634124000@Atlassian.JIRA>
References: <JIRA.13027782.1481634124000@Atlassian.JIRA> <JIRA.13027782.1481634124528@arcas>
Subject: [jira] [Updated] (VFS-626) Cannot open large bzip2 files
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 13 Dec 2016 13:20:00 -0000


     [ https://issues.apache.org/jira/browse/VFS-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandre Sieira updated VFS-626:
---------------------------------
    Description: 
I was having problems reading a large bzip2 file in which only a part of the data was being read. So Googling a bit I came across this Apache Commons Compress issue: https://issues.apache.org/jira/browse/COMPRESS-224

When looking at https://github.com/apache/commons-vfs/blob/7b42b5598774a40487dd59d699f5f865962822d9/core/src/main/java/org/apache/commons/vfs2/provider/bzip2/Bzip2FileObject.java#L61 we can see that the BZip2CompressorInputStream constructor option `decompressConcatenated` is not defined and defaults to false, which can cause the observed behavior. This manifests itself in multi-stream bzip2 files, which tends to be the case with larger files.

I would suggest that this BZip2CompressorInputStream constructor option is explicitly set to true. It is a one-liner fix.

  was:
I was having problems reading a large bzip2 file and came across this Apache Commons Compress issue: https://issues.apache.org/jira/browse/COMPRESS-224

When looking at https://github.com/apache/commons-vfs/blob/7b42b5598774a40487dd59d699f5f865962822d9/core/src/main/java/org/apache/commons/vfs2/provider/bzip2/Bzip2FileObject.java#L61 we can see that the BZip2CompressorInputStream constructor option `decompressConcatenated` is not defined and defaults to false, which can cause the observed behavior.

I would suggest that this BZip2CompressorInputStream constructor option is explicitly set to true.


> Cannot open large bzip2 files
> -----------------------------
>
>                 Key: VFS-626
>                 URL: https://issues.apache.org/jira/browse/VFS-626
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.1
>            Reporter: Alexandre Sieira
>              Labels: easyfix
>
> I was having problems reading a large bzip2 file in which only a part of the data was being read. So Googling a bit I came across this Apache Commons Compress issue: https://issues.apache.org/jira/browse/COMPRESS-224
> When looking at https://github.com/apache/commons-vfs/blob/7b42b5598774a40487dd59d699f5f865962822d9/core/src/main/java/org/apache/commons/vfs2/provider/bzip2/Bzip2FileObject.java#L61 we can see that the BZip2CompressorInputStream constructor option `decompressConcatenated` is not defined and defaults to false, which can cause the observed behavior. This manifests itself in multi-stream bzip2 files, which tends to be the case with larger files.
> I would suggest that this BZip2CompressorInputStream constructor option is explicitly set to true. It is a one-liner fix.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)