[jira] [Updated] (COMPRESS-181) Tar files created by AIX native tar, and which contain symlinks, cannot be read by TarArchiveInputStream
[
https://issues.apache.org/jira/browse/COMPRESS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-181:
Affects Version/s: (was: 1.4)
> Tar files created by AIX native tar, and which contain symlinks, cannot be
> read by TarArchiveInputStream
>
>
> Key: COMPRESS-181
> URL: https://issues.apache.org/jira/browse/COMPRESS-181
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.2, 1.3
> Environment: AIX 5.3
>Reporter: Robert Clark
> Fix For: 1.4
>
> Attachments: simple-aix-native-tar.tar
>
>
> A simple tar file created on AIX using the native ({{/usr/bin/tar}} tar
> utility) *and* which contains a symbolic link, cannot be loaded by
> TarArchiveInputStream:
> {noformat}
> java.io.IOException: Error detected parsing the header
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:201)
> at Extractor.extract(Extractor.java:13)
> at Extractor.main(Extractor.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> at
> org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:390)
> at org.apache.tools.ant.Target.performTasks(Target.java:411)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
> at org.apache.tools.ant.Main.runBuild(Main.java:809)
> at org.apache.tools.ant.Main.startAnt(Main.java:217)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> Caused by: java.lang.IllegalArgumentException: Invalid byte 0 at offset 0 in
> '{NUL}1722000726 ' len=12
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:99)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:819)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:314)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:199)
> ... 29 more
> {noformat}
> Tested with 1.2 and the 1.4 nightly build from Feb 23
> ({{Implementation-Build: trunk@r1292625; 2012-02-23 03:20:30+}})
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-182) Support big or even negative numbers in all numeric TAR headers
[ https://issues.apache.org/jira/browse/COMPRESS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-182: Description: This is a superset of the functionality that addressed COMPRESS-175 Jörg Schillig's star and GNU tar may use binary encoding for all numeric fields, PAX/POSIX also provides them inside the extension headers. The timestamp field may even contain negative numbers. IMHO Commons Compress should: * be able to parse numeric fields using binary encoding (positive and negative) * fix the current binary parser (see discussion in COMPRESS-16) and add a workaround for broken writers (see COMPRESS-181) * be able to parse all standard fields of PAX headers, including the numeric ones (I haven't checked, maybe it already does) * have an option to write numbers too big/small in binary encoding much like BIGFILE_STAR does for the file size in trunk * have an option to write numbers too big/small in PAX headers much like BIGFILE_POSIX does for the file size in trunk * replace bigFileMode and the constants with a more generic property that controls all numeric fields. We can remove the bigFileMode stuff as it has been added after the 1.3 release. was: This is a superset of the functionality that addressed COMPRESS-175 Jörg Schillig's star and GNU tar may use binary encoding for all numeric fields, PAX/POSIX also provides them inside the extension headers. The timestamp field may even contain negative numbers. IMHO Commons Compress should: * be able to parse numeric fields using binary encoding (positive and negative) * fix the current binary parser (see discussion in COMPRESS-16) and add a workaround for broken writers (see COMPRESS-181 * be able to parse all standard fields of PAX headers, including the numeric ones (I haven't checked, maybe it already does) * have an option to write numbers too big/small in binary encoding much like BIGFILE_STAR does for the file size in trunk * have an option to write numbers too big/small in PAX headers much like BIGFILE_POSIX does for the file size in trunk * replace bigFileMode and the constants with a more generic property that controls all numeric fields. We can remove the bigFileMode stuff as it has been added after the 1.3 release. > Support big or even negative numbers in all numeric TAR headers > --- > > Key: COMPRESS-182 > URL: https://issues.apache.org/jira/browse/COMPRESS-182 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.3 >Reporter: Stefan Bodewig > Fix For: 1.4 > > > This is a superset of the functionality that addressed COMPRESS-175 > Jörg Schillig's star and GNU tar may use binary encoding for all numeric > fields, PAX/POSIX also provides them inside the extension headers. > The timestamp field may even contain negative numbers. > IMHO Commons Compress should: > * be able to parse numeric fields using binary encoding (positive and > negative) > * fix the current binary parser (see discussion in COMPRESS-16) and add a > workaround for broken writers (see COMPRESS-181) > * be able to parse all standard fields of PAX headers, including the numeric > ones (I haven't checked, maybe it already does) > * have an option to write numbers too big/small in binary encoding much like > BIGFILE_STAR does for the file size in trunk > * have an option to write numbers too big/small in PAX headers much like > BIGFILE_POSIX does for the file size in trunk > * replace bigFileMode and the constants with a more generic property that > controls all numeric fields. We can remove the bigFileMode stuff as it has > been added after the 1.3 release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-176:
Attachment: test-doublevertical.zip
MkZip.java
The attached ZIP (created by the trivial attached class) contains a file named
‖.txt and its parent directory ‖ (that's a double vertical bar) using Unicode
extra fields (and nothing else) and forward slashes.
Can you please verify WinZIP is able to extract it?
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: MkZip.java, test-7zip.zip, test-doublevertical.zip,
> test-windows.zip, test-winzip.zip, testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-176:
Fix Version/s: 1.4
> ArchiveInputStream#getNextEntry(): Problems with WinZip directories with
> Umlauts
>
>
> Key: COMPRESS-176
> URL: https://issues.apache.org/jira/browse/COMPRESS-176
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
> Environment: Windows 7
>Reporter: Wurstbrot mit Senf
>Assignee: Stefan Bodewig
> Fix For: 1.4
>
> Attachments: test-7zip.zip, test-windows.zip, test-winzip.zip,
> testzap-winzip.zip
>
>
> There is a problem when handling a WinZip-created zip with Umlauts in
> directories.
> I'm accessing a zip file created with WinZip containing a directory with an
> umlaut ("ä") with ArchiveInputStream. When creating the zip file the
> unicode-flag of winzip had been active.
> The following problem occurs when accessing the entries of the zip:
> the ArchiveEntry for a directory containing an umlaut is not marked as a
> directory and the file names for the directory and all files contained in
> that directory contain backslashes instead of slashes (i.e. completely
> different to all other files in directories with no umlaut in their path).
> There is no difference when letting the ArchiveStreamFactory decide which
> ArchiveInputStream to create or when using the ZipArchiveInputStream
> constructor with the correct encoding (I've tried different encodings CP437,
> CP850, ISO-8859-15, but still the problem persisted).
> This problem does not occur when using the very same zip file but compressed
> by 7zip or the built-in Windows 7 zip functionality.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-167) Parsing of Pax headers is not correct for values that contain embedded newlines
[ https://issues.apache.org/jira/browse/COMPRESS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-167: Fix Version/s: 1.4 Assignee: Stefan Bodewig > Parsing of Pax headers is not correct for values that contain embedded > newlines > --- > > Key: COMPRESS-167 > URL: https://issues.apache.org/jira/browse/COMPRESS-167 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.3 >Reporter: Stefan Bodewig >Assignee: Stefan Bodewig > Fix For: 1.4 > > > See > https://issues.apache.org/jira/browse/COMPRESS-163?focusedCommentId=13163674&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13163674 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-163) Unable to extract a file larger than 8GB from a Posix-format tar archive
[ https://issues.apache.org/jira/browse/COMPRESS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-163: Fix Version/s: (was: 1.3) 1.4 > Unable to extract a file larger than 8GB from a Posix-format tar archive > > > Key: COMPRESS-163 > URL: https://issues.apache.org/jira/browse/COMPRESS-163 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.3 > Environment: The tar archive used for testing was created by GNU tar, > but the problem will occur with any Posix-formatted tar file containing files > over 8GB in size. >Reporter: John Kodis >Priority: Minor > Fix For: 1.4 > > Attachments: > 0003-Allow-reading-large-files-from-Posix-tar-archives.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > An attempt to read a posix-format tar archive containing a file in excess of > 8^11 bytes in size will fail with a "Size out of range" illegal argument > exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-156) XZ compression support
[ https://issues.apache.org/jira/browse/COMPRESS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-156: Fix Version/s: 1.4 > XZ compression support > -- > > Key: COMPRESS-156 > URL: https://issues.apache.org/jira/browse/COMPRESS-156 > Project: Commons Compress > Issue Type: New Feature > Components: Compressors >Reporter: Lasse Collin > Fix For: 1.4 > > Attachments: xz_support.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-36: --- Attachment: 5GB_of_Zeros_PKZip.zip Test archive for PKZip, 100k files archive is at http://people.apache.org/~bodewig/commons-compress/ > Add Zip64 Suport > > > Key: COMPRESS-36 > URL: https://issues.apache.org/jira/browse/COMPRESS-36 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Christian Grobmeier >Assignee: Stefan Bodewig > Fix For: 1.3 > > Attachments: 5GB_of_Zeros.zip, 5GB_of_Zeros_7ZIP.zip, > 5GB_of_Zeros_PKZip.zip, 5GB_of_Zeros_WinZip.zip, > 5GB_of_Zeros_WindowsCompressedFolders.zip, 5GB_of_Zeros_jar.zip, > zip64-sample.zip > > > Add Zip64 support. This will make it work to deal with zipfiles > 2 GB. > Planned for compress 1.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-158) Empty directories missing in zip archive
[ https://issues.apache.org/jira/browse/COMPRESS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-158: Attachment: output.zip > Empty directories missing in zip archive > > > Key: COMPRESS-158 > URL: https://issues.apache.org/jira/browse/COMPRESS-158 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.2 > Environment: Java 1.6, Ubuntu Linux (ext4 fs) >Reporter: Daniel Spicar >Priority: Minor > Attachments: CompressionUtil.java, output.zip, test.zip > > > When zipping a directory that contains several files and subdirectories of > which some can be empty, I am missing empty directories. When using a tar > archive format empty directories are present. > I have found https://issues.apache.org/jira/browse/COMPRESS-105 which > describes a similar issue, however I am unable to reproduce the solution > suggested there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
