[jira] [Resolved] (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 resolved COMPRESS-163. - Resolution: Fixed The setSize Method is also used when creating entries prior to writing them and as long as Compress is unable to write archives with entries bigger than 8GiB it is better to keep the exception. Therefore I opted to add a new setter method with svn revision 1211393 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] [Created] (COMPRESS-165) Support writing entries 8GiB in tar
Support writing entries 8GiB in tar - Key: COMPRESS-165 URL: https://issues.apache.org/jira/browse/COMPRESS-165 Project: Commons Compress Issue Type: New Feature Components: Archivers Affects Versions: 1.3 Reporter: Stefan Bodewig We already parse PAX headers and the star/GNU tar/BSD tar dialects used for big entries. Similar to the way we handle long file names there should be a user option to chose between error, star and posix or pax. star is Jörg Schilling's tar which was the first one to use the binary size representation later adopted by GNU and BSD tar as well. -- 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] [Created] (COMPRESS-166) Support POSIX/Pax variant for long file names in tar
Support POSIX/Pax variant for long file names in tar Key: COMPRESS-166 URL: https://issues.apache.org/jira/browse/COMPRESS-166 Project: Commons Compress Issue Type: Improvement Components: Archivers Affects Versions: 1.3 Reporter: Stefan Bodewig Once we add support for writing Pax headers for COMPRESS-165 it will be pretty easy to support the same headers for long file names as well. -- 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] [Created] (COMPRESS-167) Parsing of Pax headers is not correct for values that contain embedded newlines
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 See https://issues.apache.org/jira/browse/COMPRESS-163?focusedCommentId=13163674page=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] [Commented] (COMPRESS-165) Support writing entries 8GiB in tar
[ https://issues.apache.org/jira/browse/COMPRESS-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164339#comment-13164339 ] Stefan Bodewig commented on COMPRESS-165: - COMPRESS-16 contains patches that enable the star method of writing such entries. Support writing entries 8GiB in tar - Key: COMPRESS-165 URL: https://issues.apache.org/jira/browse/COMPRESS-165 Project: Commons Compress Issue Type: New Feature Components: Archivers Affects Versions: 1.3 Reporter: Stefan Bodewig We already parse PAX headers and the star/GNU tar/BSD tar dialects used for big entries. Similar to the way we handle long file names there should be a user option to chose between error, star and posix or pax. star is Jörg Schilling's tar which was the first one to use the binary size representation later adopted by GNU and BSD tar as well. -- 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] [Issue Comment Edited] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164349#comment-13164349 ] Stefan Bodewig edited comment on COMPRESS-16 at 12/7/11 12:16 PM: -- writing such entries has been split out as COMPRESS-165. With svn revision 1211405 I have added tests that prove the tar package now understands both the star/GNU/BSD variant as well as the POSIX/PAX one. was (Author: bodewig): writing such entris has been split out as COMPRESS-165. With svn revision 1211405 I have added tests that prove the tar package now understand both the star/GNU/BSD variant as well as the POSIX/PAX one. unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Fix For: 1.4 Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- 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] [Resolved] (COMPRESS-16) unable to extract a TAR file that contains an entry which is 10 GB in size
[ https://issues.apache.org/jira/browse/COMPRESS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-16. Resolution: Fixed Fix Version/s: 1.4 writing such entris has been split out as COMPRESS-165. With svn revision 1211405 I have added tests that prove the tar package now understand both the star/GNU/BSD variant as well as the POSIX/PAX one. unable to extract a TAR file that contains an entry which is 10 GB in size -- Key: COMPRESS-16 URL: https://issues.apache.org/jira/browse/COMPRESS-16 Project: Commons Compress Issue Type: Bug Components: Archivers Environment: I am using win xp sp3, but this should be platform independent. Reporter: Sam Smith Fix For: 1.4 Attachments: 0001-Accept-GNU-tar-files-with-entries-over-8GB-in-size.patch, 0002-Allow-creating-tar-archives-with-files-over-8GB.patch, 0004-Prefer-octal-over-binary-size-representation.patch, ant-8GB-tar.patch, patch-for-compress.txt I made a TAR file which contains a file entry where the file is 10 GB in size. When I attempt to extract the file using TarInputStream, it fails with the following stack trace: java.io.IOException: unexpected EOF with 24064 bytes unread at org.apache.commons.compress.archivers.tar.TarInputStream.read(TarInputStream.java:348) at org.apache.commons.compress.archivers.tar.TarInputStream.copyEntryContents(TarInputStream.java:388) So, TarInputStream does not seem to support large ( 8 GB?) files. Here is something else to note: I created that TAR file using TarOutputStream , which did not complain when asked to write a 10 GB file into the TAR file, so I assume that TarOutputStream has no file size limits? That, or does it silently create corrupted TAR files (which would be the worst situation of all...)? -- 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=13163674page=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] [Created] (MATH-720) RandomDataImpl uses both JDKRandomGenerator and Well19937c, while contract/javadoc only specifies Well19937c.
RandomDataImpl uses both JDKRandomGenerator and Well19937c, while
contract/javadoc only specifies Well19937c.
-
Key: MATH-720
URL: https://issues.apache.org/jira/browse/MATH-720
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dennis Hendriks
Attachments: TestRandom.java
See attached unit test. I create a distribution, sample it (not printed), set
the seed to 0, and then print the next sample. I also create the same
distribution again, set the seed to 0, and then print the next sample. I expect
the same sample, as in both cases the seed was set to 0, just before sampling.
I however get this output:
{code}
5
4
{code}
The problem is in the org.apache.commons.math.random.RandomDataImpl class:
- The RandomDataImpl(RandomGenerator rand) constructor states in javadoc:
@param rand the source of (non-secure) random data (may be null, resulting in
default JDK-supplied generator)
- reSeed(long seed) method does: if (rand == null) rand = new
JDKRandomGenerator();
- reSeed() method does: if (rand == null) rand = new JDKRandomGenerator();
- class javadoc states: If no codeRandomGenerator/code is provided in the
constructor, the default is to use a Well19937c generator.
- getRan() does: if (rand == null) rand = new
Well19937c(System.currentTimeMillis() + System.identityHashCode(this));
- getRan() states in javadoc: Creates and initializes a default generator if
null. Uses a Well19937c generator with System.currentTimeMillis() +
System.identityHashCode(this)) as the default seed.
It seems that only Well19937c should be used, but the constructor javadoc, and
the implementation of the reSeed methods was not updated to match this. I think
the partial changes were done in MATH-701, more specifically, in commit
[1197626] (and related commit [1197716]).
--
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] (MATH-720) RandomDataImpl uses both JDKRandomGenerator and Well19937c, while contract/javadoc only specifies Well19937c.
[
https://issues.apache.org/jira/browse/MATH-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Hendriks updated MATH-720:
-
Attachment: TestRandom.java
TestRandom.java: shows the problem, as described in the issue description.
RandomDataImpl uses both JDKRandomGenerator and Well19937c, while
contract/javadoc only specifies Well19937c.
-
Key: MATH-720
URL: https://issues.apache.org/jira/browse/MATH-720
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dennis Hendriks
Labels: random, seed
Attachments: TestRandom.java
See attached unit test. I create a distribution, sample it (not printed), set
the seed to 0, and then print the next sample. I also create the same
distribution again, set the seed to 0, and then print the next sample. I
expect the same sample, as in both cases the seed was set to 0, just before
sampling. I however get this output:
{code}
5
4
{code}
The problem is in the org.apache.commons.math.random.RandomDataImpl class:
- The RandomDataImpl(RandomGenerator rand) constructor states in javadoc:
@param rand the source of (non-secure) random data (may be null, resulting
in default JDK-supplied generator)
- reSeed(long seed) method does: if (rand == null) rand = new
JDKRandomGenerator();
- reSeed() method does: if (rand == null) rand = new JDKRandomGenerator();
- class javadoc states: If no codeRandomGenerator/code is provided in
the constructor, the default is to use a Well19937c generator.
- getRan() does: if (rand == null) rand = new
Well19937c(System.currentTimeMillis() + System.identityHashCode(this));
- getRan() states in javadoc: Creates and initializes a default generator
if null. Uses a Well19937c generator with System.currentTimeMillis() +
System.identityHashCode(this)) as the default seed.
It seems that only Well19937c should be used, but the constructor javadoc,
and the implementation of the reSeed methods was not updated to match this. I
think the partial changes were done in MATH-701, more specifically, in commit
[1197626] (and related commit [1197716]).
--
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] [Resolved] (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 resolved COMPRESS-167. - Resolution: Invalid Fix Version/s: (was: 1.4) svn revision 1211465 contains a passing test for a PAX header with an embedded newline. 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 See https://issues.apache.org/jira/browse/COMPRESS-163?focusedCommentId=13163674page=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] [Commented] (MATH-720) RandomDataImpl uses both JDKRandomGenerator and Well19937c, while contract/javadoc only specifies Well19937c.
[
https://issues.apache.org/jira/browse/MATH-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164783#comment-13164783
]
Gilles commented on MATH-720:
-
Good catch!
This bug shows how safer it would be to have the rand field final (no need
to test for null all over the place).
RandomDataImpl uses both JDKRandomGenerator and Well19937c, while
contract/javadoc only specifies Well19937c.
-
Key: MATH-720
URL: https://issues.apache.org/jira/browse/MATH-720
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Dennis Hendriks
Labels: random, seed
Attachments: TestRandom.java
See attached unit test. I create a distribution, sample it (not printed), set
the seed to 0, and then print the next sample. I also create the same
distribution again, set the seed to 0, and then print the next sample. I
expect the same sample, as in both cases the seed was set to 0, just before
sampling. I however get this output:
{code}
5
4
{code}
The problem is in the org.apache.commons.math.random.RandomDataImpl class:
- The RandomDataImpl(RandomGenerator rand) constructor states in javadoc:
@param rand the source of (non-secure) random data (may be null, resulting
in default JDK-supplied generator)
- reSeed(long seed) method does: if (rand == null) rand = new
JDKRandomGenerator();
- reSeed() method does: if (rand == null) rand = new JDKRandomGenerator();
- class javadoc states: If no codeRandomGenerator/code is provided in
the constructor, the default is to use a Well19937c generator.
- getRan() does: if (rand == null) rand = new
Well19937c(System.currentTimeMillis() + System.identityHashCode(this));
- getRan() states in javadoc: Creates and initializes a default generator
if null. Uses a Well19937c generator with System.currentTimeMillis() +
System.identityHashCode(this)) as the default seed.
It seems that only Well19937c should be used, but the constructor javadoc,
and the implementation of the reSeed methods was not updated to match this. I
think the partial changes were done in MATH-701, more specifically, in commit
[1197626] (and related commit [1197716]).
--
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
