[jira] [Commented] (SANSELAN-17) integer overflow unhandled
[
https://issues.apache.org/jira/browse/SANSELAN-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213300#comment-13213300
]
Damjan Jovanovic commented on SANSELAN-17:
--
EXIF was changed to silently ignore bad tags when not in strict mode -
exceptions are only thrown in strict mode. It seems like a good idea to add
this for IPTC as well.
That image has multiple APP13 segments. Even if we break instead of throw when
the invalid block size happens, there is another exception later because
Sanselan doesn't handle multiple APP13 segments. Even if only the first segment
is returned there, it has no useful data.
On the other hand, there is some debate
(http://dev.robotbattle.com/bugs/view.php?id=533 and
http://uk.groups.yahoo.com/group/exiv2/message/1382) as to whether files with
multiple APP13 segments are valid, because supposedly the APP13 segments can be
joined together in some cases. Maybe when joined together than now invalid
length of 86622 becomes valid?
> integer overflow unhandled
> --
>
> Key: SANSELAN-17
> URL: https://issues.apache.org/jira/browse/SANSELAN-17
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: JPEG
>Affects Versions: 0.94-incubator
> Environment: win32, 32 bit operating systems
>Reporter: Greg Squires
> Attachments: crash.jpeg
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This function can throw an Exception in ByteSourceArray.java due to a
> negative byte[] allocation size. The length argument has been found to wrap
> when called from IccProfileParser.java.
> In 64bit machines, issues related to incorrect metadata, or ICC data can lead
> to incorrect and excess memory allocations. These large numbers however cause
> 32bit negative signed values.
> public byte[] getBlock(int start, int length) throws IOException
> {
> if (start + length > bytes.length)
> throw new IOException("Could not read block (block
> start: " + start
> + ", block length: " + length + ", data
> length: "
> + bytes.length + ").");
> byte result[] = new byte[length];
> System.arraycopy(bytes, start, result, 0, length);
> return result;
> }
--
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-176) ArchiveInputStream#getNextEntry(): Problems with WinZip directories with Umlauts
[
https://issues.apache.org/jira/browse/COMPRESS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213223#comment-13213223
]
Sebb commented on COMPRESS-176:
---
Thanks.
I'm beginning to wonder if Winzip is faulty.
The unicode filename that is stored uses \ whereas the base name uses /.
> 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
> Attachments: test-7zip.zip, test-windows.zip, test-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] (IO-302) ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without BOM multiple times
[ https://issues.apache.org/jira/browse/IO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcos Vinícius da Silva updated IO-302: Attachment: IO-302.patch Hi all! Please, take a look for this correction. I cleaned up the test case to make it more clear and cut the sample file. > ArrayIndexOutOfBoundsException in BOMInputStream when reading a file without > BOM multiple times > --- > > Key: IO-302 > URL: https://issues.apache.org/jira/browse/IO-302 > Project: Commons IO > Issue Type: Bug > Components: Streams/Writers >Affects Versions: 2.1 > Environment: Win7 64bit, Java 6 32bit >Reporter: Jan Steuerwald > Attachments: IO-302.patch, Test.java, testfileBOM.xml, > testfileNoBOM.xml > > > Resetting the BOMInputStream doesn't reset the _fbLength_ member variable. > This causes _fbLength_ to grow bigger than the _firstBytes_ array (when the > file doesn't contain a BOM), which leads to an ArrayIndexOutOfBoundsException > in the _readFirstBytes_ method. > The attached test case reveals the problem. -- 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] (FUNCTOR-1) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/FUNCTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213013#comment-13213013 ] Liviu Tudor commented on FUNCTOR-1: --- Question -- looking at FUNCTOR-4 , I need to add some examples etc for these components to make it easier for users. Where would these examples go? > [functor] New components: summarize and aggregate > - > > Key: FUNCTOR-1 > URL: https://issues.apache.org/jira/browse/FUNCTOR-1 > Project: Commons Functor > Issue Type: New Feature > Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly > 1.4 though I haven't tested). >Reporter: Liviu Tudor >Assignee: Simone Tripodi >Priority: Minor > Labels: features > Attachments: commons-functor-aggregate+summarizer.zip, > commons-functor.patch.bz2, functor.patch.bz2 > > > This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 > -- as instructed I'm finally hoping to get the code in the right place and > hopefully this is something that the functor component could do with. > Whereas initially I just started with the summarizer component, I have added > now the second one, the "aggregator" as they are somehow related. If this > code proves to be useful to functor in any way, it would actually be good to > get some feedback on these 2 to see if the class hierarchy can in fact be > changed to share some common functionality as I feel (probably due to the > similar needs that lead to writing/using these components) that somehow they > should share a common base. > In brief, the 2 components: > * aggregator: this just allows for data to be aggregated in a user defined > way (e.g. stored in a list for the purpose of averaging, computing the > arithmetic median etc). The classes provided actually offer the > implementation for storing data in a list and computing the above-mentioned > values or summing up everything. > * timed summarizer: this is another variation of the aggreator, however, it > adds the idea of regular "flushes", so based on a timer it will reset the > value and start summing/aggregating the data again. Rather than using an > aggregator which would store the whole data series (possibly for applying > more complex formulas), this component just computes on the fly on each > request the formula and stores the result of it. (Which does mean things like > computing arithmetic mean, median etc would be difficult to compute without > knowing upfront how many calls will be received -- i.e. how many elements we > will be required to summarize/aggregate.) So the memory footprint of running > this is much smaller -- even though, as I said, it achieves similar results. > I have only provided a summarizer which operates on integers, but obviously > others for float, double etc can be created if we go ahead with this design. > Hopefully the above make sense; this code has resulted from finding myself > writing similar components to these a few times and because it's always been > either one type (e.g. aggregator) or another (summarizer) I haven't given > quite possibly enough thought to the class design to join these 2. Also, > unfortunately, the time I sat down to make these components a bit more > general and submitted issue 340 was nearly 3 months ago so I'm trying to > remember myself all the ideas I had at a time so bear with me please if these > are still a bit fuzzy :) However, if you can make use of these I'm quite > happy to elaborate on areas that are unclear and obviously put some effort > into getting these components to the standards required to put these into a > 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] (MATH-749) Convex Hull algorithm
[ https://issues.apache.org/jira/browse/MATH-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-749: - Description: It would be nice to have convex hull implementations for 2D/3D space. There are several known algorithms [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: * Graham scan: O(n log n) * Incremental: O(n log n) * Kirkpatrick-Seidel: O(n log h) * Chan: O(n log h) The preference would be on an algorithm that is easily extensible for higher dimensions, TBD. was:It would be nice to have an implementation of Graham's scan algorithm to compute the convex hull of a set of points in a plane. > Convex Hull algorithm > - > > Key: MATH-749 > URL: https://issues.apache.org/jira/browse/MATH-749 > Project: Commons Math > Issue Type: New Feature >Reporter: Thomas Neidhart >Priority: Minor > Labels: 2d, geometric > Fix For: 3.1 > > > It would be nice to have convex hull implementations for 2D/3D space. There > are several known algorithms > [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: > * Graham scan: O(n log n) > * Incremental: O(n log n) > * Kirkpatrick-Seidel: O(n log h) > * Chan: O(n log h) > The preference would be on an algorithm that is easily extensible for higher > dimensions, TBD. -- 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-749) Convex Hull algorithm
[ https://issues.apache.org/jira/browse/MATH-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated MATH-749: - Description: It would be nice to have convex hull implementations for 2D/3D space. There are several known algorithms [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: * Graham scan: O(n log n) * Incremental: O(n log n) * Divide and Conquer: O(n log n) * Kirkpatrick-Seidel: O(n log h) * Chan: O(n log h) The preference would be on an algorithm that is easily extensible for higher dimensions, so *Incremental* and *Divide and Conquer* would be prefered. was: It would be nice to have convex hull implementations for 2D/3D space. There are several known algorithms [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: * Graham scan: O(n log n) * Incremental: O(n log n) * Kirkpatrick-Seidel: O(n log h) * Chan: O(n log h) The preference would be on an algorithm that is easily extensible for higher dimensions, TBD. > Convex Hull algorithm > - > > Key: MATH-749 > URL: https://issues.apache.org/jira/browse/MATH-749 > Project: Commons Math > Issue Type: New Feature >Reporter: Thomas Neidhart >Priority: Minor > Labels: 2d, geometric > Fix For: 3.1 > > > It would be nice to have convex hull implementations for 2D/3D space. There > are several known algorithms > [http://en.wikipedia.org/wiki/Convex_hull_algorithms]: > * Graham scan: O(n log n) > * Incremental: O(n log n) > * Divide and Conquer: O(n log n) > * Kirkpatrick-Seidel: O(n log h) > * Chan: O(n log h) > The preference would be on an algorithm that is easily extensible for higher > dimensions, so *Incremental* and *Divide and Conquer* would be prefered. -- 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] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212981#comment-13212981
]
Simone Tripodi edited comment on SANDBOX-396 at 2/21/12 9:42 PM:
-
patch looks good, anyway:
{code}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{code}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} chain that
returns a {{BeanAccessor}} and would help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
was (Author: simone.tripodi):
patch looks good, anyway:
{code}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{code}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} chain that
would help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
> [BeanUtils2] Implement clone() on DefaultBeanAccessor
> -
>
> Key: SANDBOX-396
> URL: https://issues.apache.org/jira/browse/SANDBOX-396
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-396.txt
>
>
> Implement {{clone()}} on DefaultBeanAccessor:
> * create a new instance of the same type as the bean encapsulated by the
> Accessor
> * create a {{DefaultBeanAccessor}} for the new instance
> * call populate on the new {{DefaultBeanAccessor}} with {{this.describe()}}
> as argument
> * return the clone
--
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] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212981#comment-13212981
]
Simone Tripodi edited comment on SANDBOX-396 at 2/21/12 9:42 PM:
-
patch looks good, anyway:
{code}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{code}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} chain that
would help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
was (Author: simone.tripodi):
patch looks good, anyway:
{quote}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{quote}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} that would
help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
> [BeanUtils2] Implement clone() on DefaultBeanAccessor
> -
>
> Key: SANDBOX-396
> URL: https://issues.apache.org/jira/browse/SANDBOX-396
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-396.txt
>
>
> Implement {{clone()}} on DefaultBeanAccessor:
> * create a new instance of the same type as the bean encapsulated by the
> Accessor
> * create a {{DefaultBeanAccessor}} for the new instance
> * call populate on the new {{DefaultBeanAccessor}} with {{this.describe()}}
> as argument
> * return the clone
--
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] (SANDBOX-396) [BeanUtils2] Implement clone() on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212981#comment-13212981
]
Simone Tripodi commented on SANDBOX-396:
patch looks good, anyway:
{quote}
+@SuppressWarnings( "unchecked" )
+B clone = (B) bean.getClass().newInstance();
+DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
clone );
+cloneAccessor.populate( this.describe() );
+return clone;
{quote}
* it is a good practice adding a comment that justifies why the unchecked
warning can be suppressed;
* the {{this.}} prefix can be omitted.
We could even reuse the {{BeanUtils.on( beanType ).newInstance()}} that would
help removing the duplicated code.
Can you please apply these modifications and resubmit the patch?
TIA,
-Simo
> [BeanUtils2] Implement clone() on DefaultBeanAccessor
> -
>
> Key: SANDBOX-396
> URL: https://issues.apache.org/jira/browse/SANDBOX-396
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: BeanUtils2
>Affects Versions: Nightly Builds
>Reporter: Benedikt Ritter
> Attachments: SANDBOX-396.txt
>
>
> Implement {{clone()}} on DefaultBeanAccessor:
> * create a new instance of the same type as the bean encapsulated by the
> Accessor
> * create a {{DefaultBeanAccessor}} for the new instance
> * call populate on the new {{DefaultBeanAccessor}} with {{this.describe()}}
> as argument
> * return the clone
--
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] (SANDBOX-395) Correct names for classes and variables related to operations on weights
[
https://issues.apache.org/jira/browse/SANDBOX-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212973#comment-13212973
]
Simone Tripodi commented on SANDBOX-395:
Hi Claudio,
please commit it! eventual modifications can be performed while working, I'm
confident you know very well the topic ;)
Best,
-Simo
> Correct names for classes and variables related to operations on weights
>
>
> Key: SANDBOX-395
> URL: https://issues.apache.org/jira/browse/SANDBOX-395
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: Graph
>Reporter: Claudio Squarcella
>Assignee: Claudio Squarcella
>Priority: Minor
> Labels: graph, operations, weight
> Attachments:
> SANDBOX-395_CorrectClassAndVariableNamesForWeightOperations.patch
>
>
> Hi all,
> as discussed in ML already the current classes/variables that refer to
> operations on weights can be renamed for better expressiveness:
> * all the classes under {{weight.primitive}} should be renamed from {{XXX}}
> to {{XXXOperations}} because they actually contain operations on weights
> (they do not represent weights themselves);
> * in the actual algorithms, all variable names for weight operations should
> actually be something like {{weightOperations}} instead of the name of the
> interface (e.g. {{orderedMonoid}}).
--
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] (EMAIL-101) Specified Content-ID is not used when embedding a File object in an HtmlEmail
[ https://issues.apache.org/jira/browse/EMAIL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siegfried Goeschl updated EMAIL-101: Attachment: EMAIL-101.patch Updated patch (hackergarden vienna) > Specified Content-ID is not used when embedding a File object in an HtmlEmail > - > > Key: EMAIL-101 > URL: https://issues.apache.org/jira/browse/EMAIL-101 > Project: Commons Email > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2 >Reporter: Andrew Starodub >Assignee: Siegfried Goeschl >Priority: Minor > Fix For: 1.3 > > Attachments: EMAIL-101.patch, HtmlEmail.patch, HtmlEmailTest.patch > > > When calling the .embed(File file, String cid) method on HtmlEmail, the cid > argument is never used within the method. > Consequently, even when the user specifies a Content-ID for the embedded > File, a new randomly generated Content-ID is generated every time. > I believe this is as simple as changing the last line of .embed(File file, > String cid) from: > return embed(new FileDataSource(file), file.getName()); > To: > return embed(new FileDataSource(file), file.getName(), cid); -- 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] (DAEMON-242) jsvc cannot find libcap.so on debian-based distributions
jsvc cannot find libcap.so on debian-based distributions Key: DAEMON-242 URL: https://issues.apache.org/jira/browse/DAEMON-242 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.9 Environment: Debian 6.0.2 Ubuntu 11.04 Reporter: Phil Clay Debian-based distributions do not symlink the "main" shared object to the major version. For example: On RHEL4u4: $ ls -l /lib/libcap.so* lrwxrwxrwx 1 root root11 Jun 13 2007 /lib/libcap.so -> libcap.so.1 lrwxrwxrwx 1 root root14 Jun 12 2007 /lib/libcap.so.1 -> libcap.so.1.10 -rwxr-xr-x 1 root root 11784 Oct 7 2006 /lib/libcap.so.1.10 Notice libcap.so -> libcap.so.1 On Debian 6.02: $ ls -l /lib/libcap.so* lrwxrwxrwx 1 root root14 Jan 25 10:19 /lib/libcap.so.2 -> libcap.so.2.19 -rw-r--r-- 1 root root 16640 Aug 16 2010 /lib/libcap.so.2.19 On Ubuntu 11.04: $ ls -l /lib/libcap.so* lrwxrwxrwx 1 root root14 2011-07-16 09:52 /lib/libcap.so.2 -> libcap.so.2.20 -rw-r--r-- 1 root root 13816 2011-02-15 14:35 /lib/libcap.so.2.20 Notice there is no libcap.so -> libcap.so.2 Therefore, when jsvc attempts to load libcap.so, it fails... I see this when running jsvc -debug ... Attemtping to load library /lib/libcap.so Attemtping to load library /usr/lib/libcap.so failed loading capabilities library -- /usr/lib/libcap.so: cannot open shared object file: No such file or directory. set_caps(CAPS) failed for user 'oncommand' Service exit with a return value of 4 If I create the libcap.so -> libcap.so.2 symlink, it works. I'm guessing the fix for this would be to load libcap.so, libcap.so.2, libcap.so.1 in progression to see if any work. (Note that I have performed the workaround I mentioned in https://issues.apache.org/jira/browse/DAEMON-241 to get this far.) -- 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] (DAEMON-241) configure incorrectly includes -lcap in the LIBS variable in Makedefs
configure incorrectly includes -lcap in the LIBS variable in Makedefs - Key: DAEMON-241 URL: https://issues.apache.org/jira/browse/DAEMON-241 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.9 Reporter: Phil Clay The unix/configure script included in commons-daemon-1.0.9-native-src.tar.gz incorrectly includes "-lcap" in the LIBS variable in the generated Makedefs file. This causes the version of libcap on the linker machine to be required at jsvc runtime. (Which is what https://issues.apache.org/jira/browse/DAEMON-234 was trying to prevent) As a workaround, I ran autoconf to regenerate the configure script. After doing so, the newly regenerated configure script will properly exclude -lcap from the LIBS variable in Makedefs when configure is executed. So, I believe autoconf needs to be executed to regenerate the configure script included in the source tarball. -- 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-180) new String(byte[]) conversions use default encoding
new String(byte[]) conversions use default encoding --- Key: COMPRESS-180 URL: https://issues.apache.org/jira/browse/COMPRESS-180 Project: Commons Compress Issue Type: Bug Reporter: Sebb Some classes convert byte[] to String without specifying the encoding to be used; this is potentially unsafe. -- 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-179) TarUtils.formatLongOctalOrBinaryBytes() assumes the field will be 12 bytes long
TarUtils.formatLongOctalOrBinaryBytes() assumes the field will be 12 bytes long --- Key: COMPRESS-179 URL: https://issues.apache.org/jira/browse/COMPRESS-179 Project: Commons Compress Issue Type: Bug Reporter: Sebb The TarUtils.formatLongOctalOrBinaryBytes method currently assumes that the field can hold 11 octal bytes. This is not necessarily the case; the uid and gid fields (8 bytes) can potentially be encoded as binary. -- 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-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-tabpanel&focusedCommentId=13212857#comment-13212857
]
Sebb commented on COMPRESS-16:
--
The code currently does the following:
{code}
long val = buffer[offset] & 0x7f;
for (int i = 1; i < length; i++) {
// check for val overflow removed here
val = (val << 8) + (buffer[offset + i] & 0xff);
}
{code}
So the lower 7 bits of the first byte are included in the number.
With the current implementation, it is not possible to encode/decode a negative
number.
This is OK for lengths, but would obviously cause a problem for any field that
can be negative.
According to the star doc the time fields can potentially be negative.
Maybe what the star doc means is that certain fields are allowed to contain
negative numbers, in which case the first byte is all ones, but for fields that
are unsigned the lower 7 bits are treated as part of the rest of the number.
In which case, the current parse method is OK so long as it is only used for
unsigned fields.
> 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] [Commented] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212855#comment-13212855
]
Thomas Neidhart commented on MATH-746:
--
Checked and corrected user guide for stat.inference and filter packages.
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
> * Check the user guide
--
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] (SANSELAN-33) Add a field with the raw bytes in org.apache.sanselan.formats.jpeg.iptc.IPTCRecord
[ https://issues.apache.org/jira/browse/SANSELAN-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-33. -- Resolution: Fixed Fix Version/s: 1.0 Added in commit 1291967, resolving FIXED. > Add a field with the raw bytes in > org.apache.sanselan.formats.jpeg.iptc.IPTCRecord > -- > > Key: SANSELAN-33 > URL: https://issues.apache.org/jira/browse/SANSELAN-33 > Project: Commons Sanselan > Issue Type: Improvement >Reporter: Olivier Voortman >Priority: Trivial > Fix For: 1.0 > > Original Estimate: 10m > Remaining Estimate: 10m > > Hi there, > I was wondering if you could add a field with the raw bytes of the > IPTCRecord, such as : > public final byte[] data; or with a getter(). > Because when the IPTCParser creates each IPTCRecord, it assumes the record is > using the ISO-8859-1 charset, which of course is not always the case. > It would be nice to perform some automatic charset detection in there too. > But having access to the raw bytes can be usefull anyway, if for some reason > the record is not a string. > Thanks already! -- 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-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-tabpanel&focusedCommentId=13212801#comment-13212801 ] John Kodis commented on COMPRESS-16: I believe that only the most significant bit of the first byte is used to signal a binary length field. This is what GNU tar does, and seems to match both the Wikipedia description of the tar file format (http://en.wikipedia.org/wiki/Tar_%28file_format%29) and the star man page referenced previously. Wikipedia claims: "To overcome this limitation, star in 2001 introduced a base-256 coding that is indicated by setting the high-order bit of the leftmost byte of a numeric field. GNU-tar and BSD-tar followed this idea." While the star man page says that: "Star implements a vendor specific (and thus non-POSIX) extension to put bigger numbers into the numeric fields. This is done by using a base 256 coding. The top bit of the first character in the appropriate 8 character or 12 charac- ter field is set to flag non octal coding. If base 256 cod- ing is in use, then all remaining characters are used to code the number. This results in 7 base 256 digits in 8 character fields and in 11 base 256 digits in 12 character fields. All base 256 numbers are two's complement numbers. A base 256 number in a 8 character field may hold 56 bits, a base 256 number in a 12 character field may hold 88 bits. This may extended to 64 bits for 8 character fields and to 95 bits for 12 character fields. For a negative number the first character currently is set to a value of 255 (all 8 bits are set). Since we don't have to worry about negative values when dealing with file sizes, I believe that the current patch is correct as it stands, at least up to the size allowed by Java's 64 bit signed long integers. > 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] (SANSELAN-25) Support for reading Radiance HDR images
[ https://issues.apache.org/jira/browse/SANSELAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-25. -- Resolution: Fixed Fix Version/s: 1.0 Code, tests, and sample image imported in commit 1291956. Thank you for your contribution! Resolving FIXED. > Support for reading Radiance HDR images > --- > > Key: SANSELAN-25 > URL: https://issues.apache.org/jira/browse/SANSELAN-25 > Project: Commons Sanselan > Issue Type: New Feature >Reporter: peter royal > Fix For: 1.0 > > > I have added support for reading Radiance HDR images to Sanselan. The code is > available at http://github.com/osi/sanselan/tree/radiance-hdr > If the changes look good (i was specifically curious about > http://github.com/osi/sanselan/commit/f29c13db8479aca7b421876fcc001d180d384458#L0R92 > relative to the overall library design), I can commit them as I have commons > commit privs. > Just wanted to raise this as an issue prior to just slamming changes in :) -- 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-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-tabpanel&focusedCommentId=13212741#comment-13212741 ] Stefan Bodewig commented on COMPRESS-16: Sorry, I saw COMPRESS-177 but am too busy to look into it right now. The test in TarUtils only checks whether the most significant bit is set, it doesn't check the actual value of the first byte so 0xFF should be detected as well. I haven't checked whether the end result is a negative number, though. > 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-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schlichtherle updated COMPRESS-177:
-
Comment: was deleted
(was: What's wrong with this issue? The subject says it all, I think.)
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
(r1291896)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
r1244996)
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621) (/) (r1291896)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740) (/)
> (r1291896)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) (r1244855)
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) (r1244975)
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) (r1244992, removed in
> r1244996)
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
> * Check the user guide
--
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] [Reopened] (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 ] Sebb reopened COMPRESS-16: -- I'm not sure the treatment of the leading byte is correct. star [1] says that the value can be 0x80 or 0xFF. [1] http://cdrecord.berlios.de/private/man/star/star.4.html > 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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
** List of new features
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
> ** List of new features
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
> in {{r1244996}})
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
> * Check the user guide
--
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-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212657#comment-13212657
]
Gili edited comment on COMPRESS-177 at 2/21/12 3:29 PM:
I filed a separate issue for the wrong exception type being thrown:
https://issues.apache.org/jira/browse/COMPRESS-178
was (Author: cowwoc):
I filed a second issue: https://issues.apache.org/jira/browse/COMPRESS-178
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212657#comment-13212657
]
Gili commented on COMPRESS-177:
---
I filed a second issue: https://issues.apache.org/jira/browse/COMPRESS-178
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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
]
Wurstbrot mit Senf updated COMPRESS-176:
Attachment: test-winzip.zip
test-7zip.zip
test-windows.zip
re-added winzip zip file plus identical ones packed with 7zip and windows
built-in zip facility.
> 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
> Attachments: test-7zip.zip, test-windows.zip, test-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] [Created] (COMPRESS-178) TarArchiveInputStream throws IllegalArgumentException instead of IOException
TarArchiveInputStream throws IllegalArgumentException instead of IOException
Key: COMPRESS-178
URL: https://issues.apache.org/jira/browse/COMPRESS-178
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.3
Reporter: Gili
TarArchiveInputStream is throwing IllegalArgumentException instead of
IOException on corrupt files, in direct contradiction to the Javadoc. Here is a
stack-trace:
{code}
java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in '' len=8
at
org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
at
de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
at
de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
at
de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
at
de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
at
de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
at
de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
at
de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
at
de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
at
de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
at
de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
at
de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
at
de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
at
de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
at
de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
at
de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
at
de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
at
de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
at
de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
at
de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
at java.nio.file.Files.newDirectoryStream(Files.java:400)
at
com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
at
com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
at
com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
... 20 more
{code}
Expected behavior: TarArchiveInputStream should wrap the
IllegalArgumentException in an IOException.
--
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-177) TarArchiveInputStream rejects valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gili updated COMPRESS-177:
--
Summary: TarArchiveInputStream rejects valid TAR file (was:
TarArchiveInputStream throws IllegalArgumentException on valid TAR file)
> TarArchiveInputStream rejects valid TAR file
>
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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] (SANSELAN-63) Audit and fix resource leaks
[
https://issues.apache.org/jira/browse/SANSELAN-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212649#comment-13212649
]
Damjan Jovanovic commented on SANSELAN-63:
--
Ok I've hacked MCLIRR to work, and committed your patch. Thank you for your
contribution.
It finds all kinds of problems, but doesn't find the resource leak in
BmpImageParser :-(. Maybe because ByteSource.getInputStream() returns the
stream, and FindBugs can only find streams that leak within a method? Either
way, I'll audit all the calls to ByteSource.getInputStream().
> Audit and fix resource leaks
>
>
> Key: SANSELAN-63
> URL: https://issues.apache.org/jira/browse/SANSELAN-63
> Project: Commons Sanselan
> Issue Type: Bug
>Affects Versions: 0.97
> Environment: Windows 7, Java 1.7.0.1, 0.97-Incubator
>Reporter: Adrian Moerchen
> Attachments:
> 380440_295155317172029_185275861493309_985773_37867068_n.bmp, finbugs.patch
>
>
> The attached image is somehow corrupt (it still can be opened with IrfanView).
> Trying to read the image information with {{Sanselan.getImageInfo(file)}}
> results in an IOException.
> After this the image is still locked on the file system, and can't be deleted
> for example. I expected it to be immediately get unlocked on the file system,
> after the error occured.
--
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-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212648#comment-13212648
]
Christian Schlichtherle commented on COMPRESS-177:
--
What's wrong with this issue? The subject says it all, I think.
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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
]
Wurstbrot mit Senf updated COMPRESS-176:
Attachment: (was: test-winzip.zip)
> 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
>
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=13212641#comment-13212641
]
Sebb commented on COMPRESS-176:
---
Thanks, but you have not granted the ASF licence to use the file, which means
we cannot include it in our test suite.
Please could you delete and reattach it?
Also, we will need the equivalent 7zip and Win7 archives for comparison.
> 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
> Attachments: test-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] [Commented] (COMPRESS-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212637#comment-13212637
]
Sebb commented on COMPRESS-177:
---
Please raise a separate JIRA issue for changing the exception type.
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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
]
Wurstbrot mit Senf updated COMPRESS-176:
Attachment: test-winzip.zip
Minimum test zip attached.
> 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
> Attachments: test-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] [Commented] (COMPRESS-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212633#comment-13212633
]
Christian Schlichtherle commented on COMPRESS-177:
--
Yes, please wrap it in an IOE because in the context of
TarInputStream.getArchiveEntry() it's not an illegal argument, but an invalid
file content, which is a side effect.
In comparison, java.util.zip uses ZipException, which extends IOException, to
flag invalid file contents.
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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
[jira] [Commented] (COMPRESS-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212631#comment-13212631
]
Sebb commented on COMPRESS-177:
---
Looks like the archive might be using the Joerg Schilling STAR format [1] for
numeric fields:
Star implements a vendor specific (and thus non-POSIX)
extension to put bigger numbers into the numeric fields.
This is done by using a base 256 coding. The top bit of the
first character in the appropriate 8 character or 12 charac-
ter field is set to flag non octal coding.
The value certainly makes sense in that context.
As to the exception that is thrown, IAE makes sense in the context of the
TarUtils.parseOctal() method.
Maybe that should be converted to IOE by one of the higher level methods.
[1] http://cdrecord.berlios.de/private/man/star/star.4.html
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I
[jira] [Commented] (COMPRESS-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212628#comment-13212628
]
Gili commented on COMPRESS-177:
---
Sebb,
How do WinRar and Ubuntu Archiver handle this TAR file? They don't report any
errors and extract it just fine...
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
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-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212622#comment-13212622
]
Christian Schlichtherle commented on COMPRESS-177:
--
I thought so. However, in this case the code should throw an IOException from
TarInputStream.getArchiveEntry(), not an IllegalArgumentException. This comes
completely unexpected and is misleading because it's not an illegal argument to
this method, but an invalid file content.
I an IOException were thrown as documented by the Javadoc, then the TrueZIP
Kernel would have identified it as a false positive archive file, which it is.
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is valid (opens up in WinRar and Ubuntu's built-in Archiver).
--
This message is automatically generated by JI
[jira] [Updated] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
* Check the user guide
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
> in {{r1244996}})
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
> * Check the user guide
--
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-177) TarArchiveInputStream throws IllegalArgumentException on valid TAR file
[
https://issues.apache.org/jira/browse/COMPRESS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212607#comment-13212607
]
Sebb commented on COMPRESS-177:
---
The tar file appears to be corrupt.
The file contains the following:
0060:00 00 00 00 30 30 30 30 37 35 35 00 30 30 30 31755.0001
0070:30 34 30 00 80 00 00 00 ff ff ff ff 30 30 30 30040.€...
0080:30 30 30 36 35 34 33 00 31 31 36 35 37 34 37 340006543.11657474
0090:32 36 35 00 30 32 31 32 30 36 00 20 30 00 00 265.021206. 0..
Note the strange entry starting at offset 74 - this should be the groupId.
There seem to be quite a few other entries with the same problem.
The header entries are supposed to use ASCII for portability.
> TarArchiveInputStream throws IllegalArgumentException on valid TAR file
> ---
>
> Key: COMPRESS-177
> URL: https://issues.apache.org/jira/browse/COMPRESS-177
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.3
>Reporter: Gili
>
> Issue originally reported at http://java.net/jira/browse/TRUEZIP-219
> # Download
> http://sourceforge.net/projects/boost/files/boost/1.48.0/boost_1_48_0.tar.gz?use_mirror=autoselect
> # I invoke Files.newDirectoryStream() on a TPath pointing to the resulting
> .tar.gz file
> # The following exception is thrown:
> {code}
> java.lang.IllegalArgumentException: Invalid byte -1 at offset 7 in ' bytes>' len=8
> at
> org.apache.commons.compress.archivers.tar.TarUtils.parseOctal(TarUtils.java:86)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.parseTarHeader(TarArchiveEntry.java:790)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveEntry.(TarArchiveEntry.java:308)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:198)
> at
> org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:380)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarInputShop.(TarInputShop.java:91)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newTarInputShop(TarDriver.java:159)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarGZipDriver.newTarInputShop(TarGZipDriver.java:82)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:151)
> at
> de.schlichtherle.truezip.fs.archive.tar.TarDriver.newInputShop(TarDriver.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsDefaultArchiveController.mount(FsDefaultArchiveController.java:170)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController$ResetFileSystem.autoMount(FsFileSystemArchiveController.java:98)
> at
> de.schlichtherle.truezip.fs.archive.FsFileSystemArchiveController.autoMount(FsFileSystemArchiveController.java:47)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.autoMount(FsArchiveController.java:129)
> at
> de.schlichtherle.truezip.fs.archive.FsArchiveController.getEntry(FsArchiveController.java:160)
> at
> de.schlichtherle.truezip.fs.archive.FsContextController.getEntry(FsContextController.java:117)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsDecoratingController.getEntry(FsDecoratingController.java:76)
> at
> de.schlichtherle.truezip.fs.FsConcurrentController.getEntry(FsConcurrentController.java:164)
> at
> de.schlichtherle.truezip.fs.FsSyncController.getEntry(FsSyncController.java:108)
> at
> de.schlichtherle.truezip.fs.FsFederatingController.getEntry(FsFederatingController.java:156)
> at
> de.schlichtherle.truezip.nio.file.TFileSystem.newDirectoryStream(TFileSystem.java:348)
> at
> de.schlichtherle.truezip.nio.file.TPath.newDirectoryStream(TPath.java:963)
> at
> de.schlichtherle.truezip.nio.file.TFileSystemProvider.newDirectoryStream(TFileSystemProvider.java:344)
> at java.nio.file.Files.newDirectoryStream(Files.java:400)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.convertToJar(GetSourcesMojo.java:248)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.download(GetSourcesMojo.java:221)
> at
> com.googlecode.boostmavenproject.GetSourcesMojo.execute(GetSourcesMojo.java:111)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 20 more
> {code}
> Christian Schlichtherle (the TrueZip author) is expecting the Commons
> Compress to throw IOException instead of IllegalArgumentException. I am
> expecting no exception to be thrown because as far as I can tell the TAR file
> is
[jira] [Updated] (VFS-404) [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1
[ https://issues.apache.org/jira/browse/VFS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-404: Summary: [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1 (was: Update Apache Commons Net to 3.1 from 3.0.1) > [FTP][FTPS] Update Apache Commons Net to 3.1 from 3.0.1 > --- > > Key: VFS-404 > URL: https://issues.apache.org/jira/browse/VFS-404 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.0 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_29\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory >Assignee: Gary D. Gregory > Fix For: 2.1 > > > Update Apache Commons Net to 3.1 from 3.0.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] [Created] (VFS-404) Update Apache Commons Net to 3.1 from 3.0.1
Update Apache Commons Net to 3.1 from 3.0.1 --- Key: VFS-404 URL: https://issues.apache.org/jira/browse/VFS-404 Project: Commons VFS Issue Type: Task Affects Versions: 2.0 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_29\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 2.1 Update Apache Commons Net to 3.1 from 3.0.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] (MATH-746) Things to do before releasing 3.0
[
https://issues.apache.org/jira/browse/MATH-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-746:
Description:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
* Findbugs:
** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
** org.apache.commons.math3.distribution.TriangularDistribution
** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
corrected before release)
** org.apache.commons.math3.stat.regression.RegressionResults
was:
This issue is meant to contain a list of tasks to be completed before the
release.
* Remarks to be added to the *release notes*:
** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
*** Many code paths untested
*** Looking for volunteers to improve the code readability, robustness and
performance
*** Looking for volunteers to extend the test suite
** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
* Create a "release branch"
* Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
* Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
* Remove unit test class {{BatteryNISTTest}}
* Remove class {{PivotingQRDecomposition}}
* Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
in {{r1244996}})
> Things to do before releasing 3.0
> -
>
> Key: MATH-746
> URL: https://issues.apache.org/jira/browse/MATH-746
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Blocker
> Fix For: 3.0
>
>
> This issue is meant to contain a list of tasks to be completed before the
> release.
> * Remarks to be added to the *release notes*:
> ** Experimental code: {{BOBYQAOptimizer}} (cf. MATH-621)
> *** Many code paths untested
> *** Looking for volunteers to improve the code readability, robustness and
> performance
> *** Looking for volunteers to extend the test suite
> ** {{FastMath}} is not always faster than {{Math}} (issue MATH-740)
> * Create a "release branch"
> * Disable CheckStyle scanning of {{BOBYQAOptimizer}} (/) ({{r1244855}})
> * Comment out "print" statements in {{BOBYQAOptimizerTest}} (/) ({{r1244975}})
> * Remove unit test class {{BatteryNISTTest}}
> * Remove class {{PivotingQRDecomposition}}
> * Comment out "print" statement in {{SymmLQTest}} (/) ({{r1244992}}) (removed
> in {{r1244996}})
> * Findbugs:
> ** org.apache.commons.math3.analysis.solvers.BaseSecantSolver
> ** org.apache.commons.math3.distribution.TriangularDistribution
> ** org.apache.commons.math3.optimization.direct.BOBYQAOptimizer (cannot be
> corrected before release)
> ** org.apache.commons.math3.stat.regression.RegressionResults
--
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] (CONFIGURATION-477) PropertyListConfiguration cannot deal with comments
[
https://issues.apache.org/jira/browse/CONFIGURATION-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212534#comment-13212534
]
Emmanuel Bourg commented on CONFIGURATION-477:
--
The specification I used to implement it didn't mention that comments were
allowed.
http://www.gnustep.org/resources/documentation/Developer/Base/Reference/NSPropertyList.html
I checked the plist parser in the OpenStep code and it does indeed skip C-style
comments (both block comments and line comments):
{code:java}
/*
* Property list parsing - skip whitespace keeping count of lines and
* regarding objective-c style comments as whitespace.
* Returns YES if there is any non-whitespace text remaining.
*/
static BOOL skipSpace(pldata *pld)
{
unsigned char c;
while (pld->pos < pld->end)
{
c = pld->ptr[pld->pos];
if (GS_IS_WHITESPACE(c) == NO)
{
if (c == '/' && pld->pos < pld->end - 1)
{
/*
* Check for comments beginning '/' followed by '/' or '*'
*/
if (pld->ptr[pld->pos + 1] == '/')
{
pld->pos += 2;
while (pld->pos < pld->end)
{code}
> PropertyListConfiguration cannot deal with comments
> ---
>
> Key: CONFIGURATION-477
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-477
> Project: Commons Configuration
> Issue Type: Bug
> Components: Format
>Affects Versions: 1.7
>Reporter: Oliver Heger
>
> According to http://code.google.com/p/networkpx/wiki/PlistSpec a plist file
> can contain C-style comments. These are currently not recognized by
> {{PropertyListConfiguration}}.
--
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] (FUNCTOR-1) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/FUNCTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Tudor updated FUNCTOR-1: -- Attachment: functor.patch.bz2 Patch as per last comment. > [functor] New components: summarize and aggregate > - > > Key: FUNCTOR-1 > URL: https://issues.apache.org/jira/browse/FUNCTOR-1 > Project: Commons Functor > Issue Type: New Feature > Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly > 1.4 though I haven't tested). >Reporter: Liviu Tudor >Assignee: Simone Tripodi >Priority: Minor > Labels: features > Attachments: commons-functor-aggregate+summarizer.zip, > commons-functor.patch.bz2, functor.patch.bz2 > > > This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 > -- as instructed I'm finally hoping to get the code in the right place and > hopefully this is something that the functor component could do with. > Whereas initially I just started with the summarizer component, I have added > now the second one, the "aggregator" as they are somehow related. If this > code proves to be useful to functor in any way, it would actually be good to > get some feedback on these 2 to see if the class hierarchy can in fact be > changed to share some common functionality as I feel (probably due to the > similar needs that lead to writing/using these components) that somehow they > should share a common base. > In brief, the 2 components: > * aggregator: this just allows for data to be aggregated in a user defined > way (e.g. stored in a list for the purpose of averaging, computing the > arithmetic median etc). The classes provided actually offer the > implementation for storing data in a list and computing the above-mentioned > values or summing up everything. > * timed summarizer: this is another variation of the aggreator, however, it > adds the idea of regular "flushes", so based on a timer it will reset the > value and start summing/aggregating the data again. Rather than using an > aggregator which would store the whole data series (possibly for applying > more complex formulas), this component just computes on the fly on each > request the formula and stores the result of it. (Which does mean things like > computing arithmetic mean, median etc would be difficult to compute without > knowing upfront how many calls will be received -- i.e. how many elements we > will be required to summarize/aggregate.) So the memory footprint of running > this is much smaller -- even though, as I said, it achieves similar results. > I have only provided a summarizer which operates on integers, but obviously > others for float, double etc can be created if we go ahead with this design. > Hopefully the above make sense; this code has resulted from finding myself > writing similar components to these a few times and because it's always been > either one type (e.g. aggregator) or another (summarizer) I haven't given > quite possibly enough thought to the class design to join these 2. Also, > unfortunately, the time I sat down to make these components a bit more > general and submitted issue 340 was nearly 3 months ago so I'm trying to > remember myself all the ideas I had at a time so bear with me please if these > are still a bit fuzzy :) However, if you can make use of these I'm quite > happy to elaborate on areas that are unclear and obviously put some effort > into getting these components to the standards required to put these into a > 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] [Commented] (FUNCTOR-1) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/FUNCTOR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212470#comment-13212470 ] Liviu Tudor commented on FUNCTOR-1: --- Hi Simone, I finally got around to doing the coding for this. Please have a look at the attached patch -- I checked the findbugs/checkstyle as instructed and as far as I can tell it looks ok. Looking forward to your comments on it! > [functor] New components: summarize and aggregate > - > > Key: FUNCTOR-1 > URL: https://issues.apache.org/jira/browse/FUNCTOR-1 > Project: Commons Functor > Issue Type: New Feature > Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly > 1.4 though I haven't tested). >Reporter: Liviu Tudor >Assignee: Simone Tripodi >Priority: Minor > Labels: features > Attachments: commons-functor-aggregate+summarizer.zip, > commons-functor.patch.bz2 > > > This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 > -- as instructed I'm finally hoping to get the code in the right place and > hopefully this is something that the functor component could do with. > Whereas initially I just started with the summarizer component, I have added > now the second one, the "aggregator" as they are somehow related. If this > code proves to be useful to functor in any way, it would actually be good to > get some feedback on these 2 to see if the class hierarchy can in fact be > changed to share some common functionality as I feel (probably due to the > similar needs that lead to writing/using these components) that somehow they > should share a common base. > In brief, the 2 components: > * aggregator: this just allows for data to be aggregated in a user defined > way (e.g. stored in a list for the purpose of averaging, computing the > arithmetic median etc). The classes provided actually offer the > implementation for storing data in a list and computing the above-mentioned > values or summing up everything. > * timed summarizer: this is another variation of the aggreator, however, it > adds the idea of regular "flushes", so based on a timer it will reset the > value and start summing/aggregating the data again. Rather than using an > aggregator which would store the whole data series (possibly for applying > more complex formulas), this component just computes on the fly on each > request the formula and stores the result of it. (Which does mean things like > computing arithmetic mean, median etc would be difficult to compute without > knowing upfront how many calls will be received -- i.e. how many elements we > will be required to summarize/aggregate.) So the memory footprint of running > this is much smaller -- even though, as I said, it achieves similar results. > I have only provided a summarizer which operates on integers, but obviously > others for float, double etc can be created if we go ahead with this design. > Hopefully the above make sense; this code has resulted from finding myself > writing similar components to these a few times and because it's always been > either one type (e.g. aggregator) or another (summarizer) I haven't given > quite possibly enough thought to the class design to join these 2. Also, > unfortunately, the time I sat down to make these components a bit more > general and submitted issue 340 was nearly 3 months ago so I'm trying to > remember myself all the ideas I had at a time so bear with me please if these > are still a bit fuzzy :) However, if you can make use of these I'm quite > happy to elaborate on areas that are unclear and obviously put some effort > into getting these components to the standards required to put these into a > 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
