[jira] [Updated] (COLLECTIONS-654) Add class SortedProperties to sort keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated COLLECTIONS-654:
-
Description: Add class {{SortedProperties}} to be used in place of
{{java.util.Properties}} to sort keys (was: Add class {{SortedProperties}} to
sort keys)
> Add class SortedProperties to sort keys
> ---
>
> Key: COLLECTIONS-654
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-654
> Project: Commons Collections
> Issue Type: New Feature
> Components: Properties
>Reporter: Gary Gregory
> Fix For: 4.2
>
>
> Add class {{SortedProperties}} to be used in place of
> {{java.util.Properties}} to sort keys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COLLECTIONS-654) Add class SortedProperties to sort keys
[
https://issues.apache.org/jira/browse/COLLECTIONS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved COLLECTIONS-654.
--
Resolution: Fixed
In git master.
> Add class SortedProperties to sort keys
> ---
>
> Key: COLLECTIONS-654
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-654
> Project: Commons Collections
> Issue Type: New Feature
> Components: Properties
>Reporter: Gary Gregory
> Fix For: 4.2
>
>
> Add class {{SortedProperties}} to sort keys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (COLLECTIONS-654) Add class SortedProperties to sort keys
Gary Gregory created COLLECTIONS-654:
Summary: Add class SortedProperties to sort keys
Key: COLLECTIONS-654
URL: https://issues.apache.org/jira/browse/COLLECTIONS-654
Project: Commons Collections
Issue Type: New Feature
Components: Properties
Reporter: Gary Gregory
Fix For: 4.2
Add class {{SortedProperties}} to sort keys
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VFS-635) can't access SMBv2
[
https://issues.apache.org/jira/browse/VFS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100580#comment-16100580
]
Gary Gregory commented on VFS-635:
--
- For a significant contributions (beyond simple patches) you will want to file
an INDIVIDUAL CONTRIBUTOR LICENSE AGREEMENT (or ICLA) with Apache; please see
https://www.apache.org/licenses/#clas
- It looks like you already license under the Apache License 2.0, so that's
good, you might want to make that more obvious by including a LICENSE file in
the root, not just a license header file.
- Then fork Apache Commons VFS and submit a PR to
https://github.com/apache/commons-vfs (with unit tests, real or mocked).
> can't access SMBv2
> --
>
> Key: VFS-635
> URL: https://issues.apache.org/jira/browse/VFS-635
> Project: Commons VFS
> Issue Type: Wish
>Affects Versions: 2.0, 2.1
>Reporter: Michael
>
> After Disabling SMBV1 in windows I can't access into the filesystem.
> This code works when SMB1 is enabled, but sops to work once disabled.
> {code}
> @Test
> public void testConnection() throws FileSystemException {
> String login = "admin";
> String password = "password";
> String domain = "";
> String folder = "//10.0.0.0/smb";
> folder = folder.replaceAll("", "/");
> StringBuilder builder = new
> StringBuilder(128).append("smb").append(':').append(folder);
> String fileURI = builder.toString();
> FileSystemOptions fsOptions = null;
> StaticUserAuthenticator auth = new
> StaticUserAuthenticator(domain, login, password);
> fsOptions = new FileSystemOptions();
>
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOptions,
> auth);
> FileSystemManager manager = VFS.getManager();
> FileSystemManager fileSystemManager = manager;
> FileObject fileObject = fileSystemManager.resolveFile(fileURI,
> fsOptions);
> boolean result = fileObject.isReadable();
> System.out.println(fileURI +" " + result);
> }
> {code}
> this is how I disabled smb v1
> Set-ItemProperty -Path
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type
> DWORD -Value 0 -Force
> How I enabled SMBV2
> Set-ItemProperty -Path
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type
> DWORD -Value 1 -Force
> https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server
> [TRACE]
> {code}
> org.apache.commons.vfs2.FileSystemException: Could not determine if file
> "smb://10.0.0.0/smb/" is readable.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761)
> at com.pa.util.files.FileUtilsTest.testConnection(FileUtilsTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
>
[jira] [Commented] (VFS-635) can't access SMBv2
[
https://issues.apache.org/jira/browse/VFS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100305#comment-16100305
]
Cody Swanson commented on VFS-635:
--
I am currently working on implementing SMB2 and 3 using smbj on Github
(https://github.com/hierynomus/smbj). What would be the best way to do this?
This will be my first time contributing to VFS, so any help is appreciated!
> can't access SMBv2
> --
>
> Key: VFS-635
> URL: https://issues.apache.org/jira/browse/VFS-635
> Project: Commons VFS
> Issue Type: Wish
>Affects Versions: 2.0, 2.1
>Reporter: Michael
>
> After Disabling SMBV1 in windows I can't access into the filesystem.
> This code works when SMB1 is enabled, but sops to work once disabled.
> {code}
> @Test
> public void testConnection() throws FileSystemException {
> String login = "admin";
> String password = "password";
> String domain = "";
> String folder = "//10.0.0.0/smb";
> folder = folder.replaceAll("", "/");
> StringBuilder builder = new
> StringBuilder(128).append("smb").append(':').append(folder);
> String fileURI = builder.toString();
> FileSystemOptions fsOptions = null;
> StaticUserAuthenticator auth = new
> StaticUserAuthenticator(domain, login, password);
> fsOptions = new FileSystemOptions();
>
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOptions,
> auth);
> FileSystemManager manager = VFS.getManager();
> FileSystemManager fileSystemManager = manager;
> FileObject fileObject = fileSystemManager.resolveFile(fileURI,
> fsOptions);
> boolean result = fileObject.isReadable();
> System.out.println(fileURI +" " + result);
> }
> {code}
> this is how I disabled smb v1
> Set-ItemProperty -Path
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type
> DWORD -Value 0 -Force
> How I enabled SMBV2
> Set-ItemProperty -Path
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type
> DWORD -Value 1 -Force
> https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server
> [TRACE]
> {code}
> org.apache.commons.vfs2.FileSystemException: Could not determine if file
> "smb://10.0.0.0/smb/" is readable.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761)
> at com.pa.util.files.FileUtilsTest.testConnection(FileUtilsTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not
[jira] [Resolved] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[ https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-418. - Resolution: Not A Bug > ZipArchiveEntry duplicates the size field from ZipEntry > --- > > Key: COMPRESS-418 > URL: https://issues.apache.org/jira/browse/COMPRESS-418 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.14 > Environment: Java 1.8.0_131 > Apache Compress 1.14 >Reporter: Darryl L. Pierce >Priority: Critical > > I create an archive using Apache Compress. I can read the archive fine using > 7zip and JAR (from the JDK). > When I read the same archive using Apache Compress libraries, I get a > NegativeArraySizeException on every entry. > When I read any other archive using Apache Compress libraries, I do not get > the NegativeArraySizeException on entries. > When I debug this, I see that the ZipArchiveEntry object has two instance > variables named size (one it defines, which contains the correct size, and > one it inherits from ZipEntry which is -1). And it seems that, on Apache > Compress-created archives, it's always returning the inherited value and not > the one defined by ZipArchiveEntry. > In my code, I am only use instances of ZipArchiveEntry. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[
https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100095#comment-16100095
]
Stefan Bodewig commented on COMPRESS-418:
-
Hmm, I'd expect the field inside {{ZipEntry}} to remain -1 all the time and the
one in {{ZipArchiveEntry}} to hold the correct value after the data has been
read.
Anyway, I'll close this for now. Thank you.
> ZipArchiveEntry duplicates the size field from ZipEntry
> ---
>
> Key: COMPRESS-418
> URL: https://issues.apache.org/jira/browse/COMPRESS-418
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
> Environment: Java 1.8.0_131
> Apache Compress 1.14
>Reporter: Darryl L. Pierce
>Priority: Critical
>
> I create an archive using Apache Compress. I can read the archive fine using
> 7zip and JAR (from the JDK).
> When I read the same archive using Apache Compress libraries, I get a
> NegativeArraySizeException on every entry.
> When I read any other archive using Apache Compress libraries, I do not get
> the NegativeArraySizeException on entries.
> When I debug this, I see that the ZipArchiveEntry object has two instance
> variables named size (one it defines, which contains the correct size, and
> one it inherits from ZipEntry which is -1). And it seems that, on Apache
> Compress-created archives, it's always returning the inherited value and not
> the one defined by ZipArchiveEntry.
> In my code, I am only use instances of ZipArchiveEntry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TEXT-98) Remove isDelimiter() and use HashSets for delimiter check
[ https://issues.apache.org/jira/browse/TEXT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099967#comment-16099967 ] ASF GitHub Bot commented on TEXT-98: Github user ameyjadiye commented on the issue: https://github.com/apache/commons-text/pull/57 @chtompki , I think whichever items are piled up for 2.x are not too critical, we should wait for 2.x release. If we are releasing some major improvement or fix we can release all queued items in that. ATM I don't see anything. > Remove isDelimiter() and use HashSets for delimiter check > - > > Key: TEXT-98 > URL: https://issues.apache.org/jira/browse/TEXT-98 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Arun Vinud >Priority: Minor > Fix For: 1.2 > > > The current implementation of *capitalize*, *uncapitalize* and *initials* in > *WordUtils* calls *isDelimiter* for every character and/or codepoint and > isDelimiter loops through the array of delimiters to check for the > occurrence. This is a bit inefficient and results in O(nk) complexity and it > can be reduced to O( n )[if n>k] or O( k ) [if k>n]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[ https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099964#comment-16099964 ] Darryl L. Pierce commented on COMPRESS-418: --- I see the overridden field while in the debugger in Eclipse; i.e., there are two fields named size visible, one with -1 and one with the correct value. But, at any rate, I guess we can consider this bug resolved in that I can work around it at least. Thank you. > ZipArchiveEntry duplicates the size field from ZipEntry > --- > > Key: COMPRESS-418 > URL: https://issues.apache.org/jira/browse/COMPRESS-418 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.14 > Environment: Java 1.8.0_131 > Apache Compress 1.14 >Reporter: Darryl L. Pierce >Priority: Critical > > I create an archive using Apache Compress. I can read the archive fine using > 7zip and JAR (from the JDK). > When I read the same archive using Apache Compress libraries, I get a > NegativeArraySizeException on every entry. > When I read any other archive using Apache Compress libraries, I do not get > the NegativeArraySizeException on entries. > When I debug this, I see that the ZipArchiveEntry object has two instance > variables named size (one it defines, which contains the correct size, and > one it inherits from ZipEntry which is -1). And it seems that, on Apache > Compress-created archives, it's always returning the inherited value and not > the one defined by ZipArchiveEntry. > In my code, I am only use instances of ZipArchiveEntry. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-98) Remove isDelimiter() and use HashSets for delimiter check
[ https://issues.apache.org/jira/browse/TEXT-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099935#comment-16099935 ] ASF GitHub Bot commented on TEXT-98: Github user chtompki commented on the issue: https://github.com/apache/commons-text/pull/57 This all opens the question about going `2.x`. I think we have a couple of things that would warrant a 2.x move. Do we want to attempt that in the fall, or is it still too premature? > Remove isDelimiter() and use HashSets for delimiter check > - > > Key: TEXT-98 > URL: https://issues.apache.org/jira/browse/TEXT-98 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Arun Vinud >Priority: Minor > Fix For: 1.2 > > > The current implementation of *capitalize*, *uncapitalize* and *initials* in > *WordUtils* calls *isDelimiter* for every character and/or codepoint and > isDelimiter loops through the array of delimiters to check for the > occurrence. This is a bit inefficient and results in O(nk) complexity and it > can be reduced to O( n )[if n>k] or O( k ) [if k>n]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[
https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099816#comment-16099816
]
Stefan Bodewig commented on COMPRESS-418:
-
No, we can't revert our hiding, unfortunately. From
http://docs.oracle.com/javase/8/docs/api/java/util/zip/package-summary.html#zip64
{quote}
An implementation may optionally support the ZIP64(tm) format extensions
defined by the PKWARE ZIP File Format Specification.
{quote}
and {{setSize}} still throws an exception for sizes bigger than 2GB if the Java
implementation doesn't support ZIP64. As Compress implements ZIP64 support
itself, we must not make ourselves depend on the Java implementation supporting
it.
> ZipArchiveEntry duplicates the size field from ZipEntry
> ---
>
> Key: COMPRESS-418
> URL: https://issues.apache.org/jira/browse/COMPRESS-418
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
> Environment: Java 1.8.0_131
> Apache Compress 1.14
>Reporter: Darryl L. Pierce
>Priority: Critical
>
> I create an archive using Apache Compress. I can read the archive fine using
> 7zip and JAR (from the JDK).
> When I read the same archive using Apache Compress libraries, I get a
> NegativeArraySizeException on every entry.
> When I read any other archive using Apache Compress libraries, I do not get
> the NegativeArraySizeException on entries.
> When I debug this, I see that the ZipArchiveEntry object has two instance
> variables named size (one it defines, which contains the correct size, and
> one it inherits from ZipEntry which is -1). And it seems that, on Apache
> Compress-created archives, it's always returning the inherited value and not
> the one defined by ZipArchiveEntry.
> In my code, I am only use instances of ZipArchiveEntry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[
https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099793#comment-16099793
]
Stefan Bodewig edited comment on COMPRESS-418 at 7/25/17 9:51 AM:
--
You will find it returns a value different from -1 once the entry's content has
been read. This is an effect of the way size is stored in ZIP archives,
depending on how the archive has been created, size is stored after the content
rather than inside the "local file header" that sits in front of the actual
data. {{ZipFile}} can use random access so is able to read all metadata for an
entry.
If you see this behavior only in achives created by Commons Compress than it is
because of the way the archive is created. If {{ZipArchiveOutputStream}} knows
it is writing to a file, it will use random access under the covers and add the
size information to the metadata in front of the entry's content. The same is
true if the {{ZipArchiveEntry}} already knows its size (compressed and
uncompressed) before you start writing, but in general you don't know the
compressed size.
{{ZipArchiveEntry}} hides the {{size}} field of {{ZipEntry}} as -the later can
only store an {{int}} while zip entries using ZIP64 extensions can store
entries with sizes that exceed {{Integer.MAX_VALUE}} - at least it used to be
an int prior to Java7, I haven't checked it afterwards (Java7 added rudimentary
support for ZIP64).- {{ZipEntry#setSize}} threw an exception prior to Java7.
Given that Compress now requires Java7, we could probably revert this.
I'm not sure how you can see the inherited size field in {{ZipEntry}} get the
correct value as {{ZipArchiveInputStream}} never sets it.
was (Author: bodewig):
You will find it returns a value different from -1 once the entry's content has
been read. This is an effect of the way size is stored in ZIP archives,
depending on how the archive has been created, size is stored after the content
rather than inside the "local file header" that sits in front of the actual
data. {{ZipFile}} can use random access so is able to read all metadata for an
entry.
If you see this behavior only in achives created by Commons Compress than it is
because of the way the archive is created. If {{ZipArchiveOutputStream}} knows
it is writing to a file, it will use random access under the covers and add the
size information to the metadata in front of the entry's content. The same is
true if the {{ZipArchiveEntry}} already knows its size (compressed and
uncompressed) before you start writing, but in general you don't know the
compressed size.
{{ZipArchiveEntry}} hides the {{size}} field of {{ZipEntry}} as the later can
only store an {{int}} while zip entries using ZIP64 extensions can store
entries with sizes that exceed {{Integer.MAX_VALUE}} - at least it used to be
an int prior to Java7, I haven't checked it afterwards (Java7 added rudimentary
support for ZIP64).
I'm not sure how you can see the inherited size field in {{ZipEntry}} get the
correct value as {{ZipArchiveInputStream}} never sets it.
> ZipArchiveEntry duplicates the size field from ZipEntry
> ---
>
> Key: COMPRESS-418
> URL: https://issues.apache.org/jira/browse/COMPRESS-418
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
> Environment: Java 1.8.0_131
> Apache Compress 1.14
>Reporter: Darryl L. Pierce
>Priority: Critical
>
> I create an archive using Apache Compress. I can read the archive fine using
> 7zip and JAR (from the JDK).
> When I read the same archive using Apache Compress libraries, I get a
> NegativeArraySizeException on every entry.
> When I read any other archive using Apache Compress libraries, I do not get
> the NegativeArraySizeException on entries.
> When I debug this, I see that the ZipArchiveEntry object has two instance
> variables named size (one it defines, which contains the correct size, and
> one it inherits from ZipEntry which is -1). And it seems that, on Apache
> Compress-created archives, it's always returning the inherited value and not
> the one defined by ZipArchiveEntry.
> In my code, I am only use instances of ZipArchiveEntry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-418) ZipArchiveEntry duplicates the size field from ZipEntry
[
https://issues.apache.org/jira/browse/COMPRESS-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099793#comment-16099793
]
Stefan Bodewig commented on COMPRESS-418:
-
You will find it returns a value different from -1 once the entry's content has
been read. This is an effect of the way size is stored in ZIP archives,
depending on how the archive has been created, size is stored after the content
rather than inside the "local file header" that sits in front of the actual
data. {{ZipFile}} can use random access so is able to read all metadata for an
entry.
If you see this behavior only in achives created by Commons Compress than it is
because of the way the archive is created. If {{ZipArchiveOutputStream}} knows
it is writing to a file, it will use random access under the covers and add the
size information to the metadata in front of the entry's content. The same is
true if the {{ZipArchiveEntry}} already knows its size (compressed and
uncompressed) before you start writing, but in general you don't know the
compressed size.
{{ZipArchiveEntry}} hides the {{size}} field of {{ZipEntry}} as the later can
only store an {{int}} while zip entries using ZIP64 extensions can store
entries with sizes that exceed {{Integer.MAX_VALUE}} - at least it used to be
an int prior to Java7, I haven't checked it afterwards (Java7 added rudimentary
support for ZIP64).
I'm not sure how you can see the inherited size field in {{ZipEntry}} get the
correct value as {{ZipArchiveInputStream}} never sets it.
> ZipArchiveEntry duplicates the size field from ZipEntry
> ---
>
> Key: COMPRESS-418
> URL: https://issues.apache.org/jira/browse/COMPRESS-418
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
> Environment: Java 1.8.0_131
> Apache Compress 1.14
>Reporter: Darryl L. Pierce
>Priority: Critical
>
> I create an archive using Apache Compress. I can read the archive fine using
> 7zip and JAR (from the JDK).
> When I read the same archive using Apache Compress libraries, I get a
> NegativeArraySizeException on every entry.
> When I read any other archive using Apache Compress libraries, I do not get
> the NegativeArraySizeException on entries.
> When I debug this, I see that the ZipArchiveEntry object has two instance
> variables named size (one it defines, which contains the correct size, and
> one it inherits from ZipEntry which is -1). And it seems that, on Apache
> Compress-created archives, it's always returning the inherited value and not
> the one defined by ZipArchiveEntry.
> In my code, I am only use instances of ZipArchiveEntry.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-417) Decompress tar.gz file failed. java.io.Exception:Error detected parsing the header
[
https://issues.apache.org/jira/browse/COMPRESS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099773#comment-16099773
]
Stefan Bodewig commented on COMPRESS-417:
-
It is available from the Apache Snapshots repository:
https://repository.apache.org/snapshots/ - more specifically
https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-compress/1.15-SNAPSHOT/
Any version built after 2017-07-20 should do.
> Decompress tar.gz file failed. java.io.Exception:Error detected parsing the
> header
> --
>
> Key: COMPRESS-417
> URL: https://issues.apache.org/jira/browse/COMPRESS-417
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
>Reporter: alphacome
>Priority: Critical
> Labels: tar
> Fix For: 1.15
>
>
> {code:java}
> public static void deGzipArchive(String filepath,String dir)
> throws Exception {
> final File input = new File(filepath);
> final InputStream is = new FileInputStream(input);
> final CompressorInputStream in = new GzipCompressorInputStream(is,
> true);
> TarArchiveInputStream tin = new TarArchiveInputStream(in);
> TarArchiveEntry entry = tin.getNextTarEntry();
> while (entry != null) {
> File archiveEntry = new File(dir, entry.getName());
> archiveEntry.getParentFile().mkdirs();
> if (entry.isDirectory()) {
> archiveEntry.mkdir();
> entry = tin.getNextTarEntry();
> continue;
> }
> OutputStream out = new FileOutputStream(archiveEntry);
> IOUtils.copy(tin, out);
> out.close();
> entry = tin.getNextTarEntry();
> }
> in.close();
> tin.close();
> }
> public static void main(String[] args) throws Exception {
>
> Gztest.deGzipArchive("D:/2102.+0800-2102.0015+0800_0.tar.gz","D:/");
> }
> {code}
> the tar.gz file can be decompressed in linux environment use 'tar' command.
> The error log:
> Exception in thread "main" java.io.IOException: Error detected parsing the
> header
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:286)
> at gztest.deGzipArchive(gztest.java:23)
> at gztest.main(gztest.java:149)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 100 at offset 0
> in 'dos{NUL}{NUL}{NUL}{NUL}{NUL}' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:141)
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:171)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1128)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1091)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:368)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:284)
> ... 2 more
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-417) Decompress tar.gz file failed. java.io.Exception:Error detected parsing the header
[
https://issues.apache.org/jira/browse/COMPRESS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16099724#comment-16099724
]
Akshay Ballarpure commented on COMPRESS-417:
I am also getting the similar issue, 1.15-SNAPSHOT will work in my case . if
so, how to download it ?
{noformat}
Untaring %s to dir %s.D:\ddc_data\010617.tar.gz D:\ddc_data
java.io.IOException: Error detected parsing the header
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:286)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:600)
at Main.unTar(Main.java:40)
at Main.extractTarGzFile(Main.java:79)
at Main.main(Main.java:108)
Caused by: java.lang.IllegalArgumentException: At offset 124, 12 byte binary
number exceeds maximum signed long value
at
org.apache.commons.compress.archivers.tar.TarUtils.parseBinaryBigInteger(TarUtils.java:213)
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:177)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1108)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1091)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:368)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:284)
... 4 more
{noformat}
> Decompress tar.gz file failed. java.io.Exception:Error detected parsing the
> header
> --
>
> Key: COMPRESS-417
> URL: https://issues.apache.org/jira/browse/COMPRESS-417
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.14
>Reporter: alphacome
>Priority: Critical
> Labels: tar
> Fix For: 1.15
>
>
> {code:java}
> public static void deGzipArchive(String filepath,String dir)
> throws Exception {
> final File input = new File(filepath);
> final InputStream is = new FileInputStream(input);
> final CompressorInputStream in = new GzipCompressorInputStream(is,
> true);
> TarArchiveInputStream tin = new TarArchiveInputStream(in);
> TarArchiveEntry entry = tin.getNextTarEntry();
> while (entry != null) {
> File archiveEntry = new File(dir, entry.getName());
> archiveEntry.getParentFile().mkdirs();
> if (entry.isDirectory()) {
> archiveEntry.mkdir();
> entry = tin.getNextTarEntry();
> continue;
> }
> OutputStream out = new FileOutputStream(archiveEntry);
> IOUtils.copy(tin, out);
> out.close();
> entry = tin.getNextTarEntry();
> }
> in.close();
> tin.close();
> }
> public static void main(String[] args) throws Exception {
>
> Gztest.deGzipArchive("D:/2102.+0800-2102.0015+0800_0.tar.gz","D:/");
> }
> {code}
> the tar.gz file can be decompressed in linux environment use 'tar' command.
> The error log:
> Exception in thread "main" java.io.IOException: Error detected parsing the
> header
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:286)
> at gztest.deGzipArchive(gztest.java:23)
> at gztest.main(gztest.java:149)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 100 at offset 0
> in 'dos{NUL}{NUL}{NUL}{NUL}{NUL}' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:141)
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctalOrBinary(TarUtils.java:171)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1128)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:1091)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:368)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:284)
> ... 2 more
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
