[jira] [Commented] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070955#comment-13070955 ] Stefan Bodewig commented on COMPRESS-36: I also have an archive with > 64k empty files via $ for a in 0 1 2 3 4 5 6 7 8 9; do for b in 0 1 2 3 4 5 6 7 8 9; do for c in 0 1 2 3 4 5 6 7 8 9; do for d in 0 1 2 3 4 5 6 7 8 9; do for e in 0 1 2 3 4 5 6 7 8 9; do mkdir -p $a/$b/$c/$d; touch $a/$b/$c/$d/$e; done; done; done; done; done $ zip -r 100k_Files.zip [0-9] but can't attach it because it is 15MB in size and exceeds the JIRA limit. Placed it in http://people.apache.org/~bodewig/commons-compress/ > Add Zip64 Suport > > > Key: COMPRESS-36 > URL: https://issues.apache.org/jira/browse/COMPRESS-36 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Christian Grobmeier >Assignee: Stefan Bodewig > Fix For: 1.3 > > Attachments: 5GB_of_Zeros.zip, zip64-sample.zip > > > Add Zip64 support. This will make it work to deal with zipfiles > 2 GB. > Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-36: --- Attachment: 5GB_of_Zeros.zip ZIP archive created by InfoZIP 3.0 from $ head -c 5GB < /dev/zero > 5GB_of_Zeros $ zip 5GB_of_Zeros.zip 5GB_of_Zeros I'm afraid we'd need to add bzip2 support in order to use the other sample first. Will check on the dev list whether it is too big to be included in svn. > Add Zip64 Suport > > > Key: COMPRESS-36 > URL: https://issues.apache.org/jira/browse/COMPRESS-36 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Reporter: Christian Grobmeier >Assignee: Stefan Bodewig > Fix For: 1.3 > > Attachments: 5GB_of_Zeros.zip, zip64-sample.zip > > > Add Zip64 support. This will make it work to deal with zipfiles > 2 GB. > Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070770#comment-13070770
]
Gilles commented on MATH-632:
-
{quote}
[...] equals has to be an equivalence relation [...]
{quote}
"==" _is_ an equivalence relation for real numbers. Nevertheless the IEEE574
deemed it important that it is broken when the floating point representation of
a real number is NaN (which is not the representation of any real number).
IIUC correctly (and probably very partially), NaNs are supposedly useful in the
implementations of algorithms (which is what CM does).
The difference between "Object" and primitive is not relevant for deciding
which is more important:
* The purpose of NaNs and conformance with a standard for the representation of
real numbers, or
* the equivalence relation of the representations of real numbers ("Double",
"double", "Complex").
To view it differently: "double" would/should not have existed in Java (as an
OO language) if it had been possible to deal exclusively with objects without a
significant loss of performance. CM uses (almost?) exclusively "double" and not
"Double"; so I think that it makes sense to ask whether or not "Complex" should
be consistent with "double" (making the examples quite relevant).
I don't understand how collections interfere with this issue...
> NaN: Method "equals" in Complex not consistent with "==" for "double"
> primitive type
>
>
> Key: MATH-632
> URL: https://issues.apache.org/jira/browse/MATH-632
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB)); // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with
> primitive "Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"),
> i.e. it is "correct" that assertion (1) is false. Do we want "Complex" to
> conform with this or with the inconsistent behaviour of "Double"?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070746#comment-13070746
]
Phil Steitz commented on MATH-632:
--
The difference between Double and double, and Complex vs double is that the
things with capital letters are *objects*. Jave *had* to define Double equals
to make NaN equal to NaN because equals has to be an equivalence relation,
which means it has to be reflexive. Personally, I don't see any problem with
Complex equals behaving differently from what we now have in MathUtils.equals,
which is a specialized method not intended to represent an equivalence relation
on objects. If we did for some reason define our own "real" object, I would
expect it to behave as Double does - making NaN equal to itself. The only
reasonable alternative to the current implementation of Complex equals (and
ArrayRealVector equals, for that matter) is to isolate every NaN-infected
instance into its own equivalence class. That is less convenient when dealing
with collections of results. Note that, like Double, we will still in any case
have to make equals reflexive, which will make it appear "inconsistent" with
the (in my mind irrelevant) examples above.
> NaN: Method "equals" in Complex not consistent with "==" for "double"
> primitive type
>
>
> Key: MATH-632
> URL: https://issues.apache.org/jira/browse/MATH-632
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB)); // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with
> primitive "Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"),
> i.e. it is "correct" that assertion (1) is false. Do we want "Complex" to
> conform with this or with the inconsistent behaviour of "Double"?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070737#comment-13070737
]
Gilles commented on MATH-632:
-
The problem starts here:
{noformat}
(x == x) is true, except when (x == NaN)
{noformat}
Some people advocate that this should not be so, i.e.
{noformat}
(x == x) is true, always
{noformat}
but IEEE574 has chosen the former. And Java primitive "double" conforms to this.
I don't understand the rationale of having decided that "Double" should behave
differently than "double", but this is beyond our reach anyway :). But, _if_
you'd have to define "equals" for "Double" wouldn't you check the equality of
the "double" returned by "doubleValue()"? In the example reported by Luc, this
is done similarly and two complex NaNs won't be equal.
What bothers me, slightly [1], is that CM is not consistent with itself: A
"Complex" instance is an abstraction/approximation of a complex number, in the
same way that a "double" is an abstraction/approximation of a real number. So
why would you consider that
{quote}
[...] it makes sense to lump all instances with NaN parts into one equivalence
class modulo equals.
{quote}
and at the same time that CM should also follow IEEE754 for "double" (cf.
"MathUtils.equals"), which is the opposite of the previous statement?
[1] Personally, I never had to use NaN beyond being a signal that there was a
bug in my code.
> NaN: Method "equals" in Complex not consistent with "==" for "double"
> primitive type
>
>
> Key: MATH-632
> URL: https://issues.apache.org/jira/browse/MATH-632
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB)); // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with
> primitive "Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"),
> i.e. it is "correct" that assertion (1) is false. Do we want "Complex" to
> conform with this or with the inconsistent behaviour of "Double"?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070664#comment-13070664 ] Sebb commented on CODEC-125: I think part of the problem might be the encoding. It looks as though the files are encoded as UTF-8, but the patch file does not specify the encoding. So the results may depend on exactly how the files are added to SVN. > Implement a Beider-Morse phonetic matching codec > > > Key: CODEC-125 > URL: https://issues.apache.org/jira/browse/CODEC-125 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matthew Pocock >Priority: Minor > Attachments: bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, > bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch > > > I have implemented Beider Morse Phonetic Matching as a codec against the > commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070634#comment-13070634 ] Sebb commented on CODEC-125: Works OK for me with Java 1.5 and Java 1.6. Perhaps you could enable the println statements as above and try again? > Implement a Beider-Morse phonetic matching codec > > > Key: CODEC-125 > URL: https://issues.apache.org/jira/browse/CODEC-125 > Project: Commons Codec > Issue Type: New Feature >Reporter: Matthew Pocock >Priority: Minor > Attachments: bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch, > bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch > > > I have implemented Beider Morse Phonetic Matching as a codec against the > commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (BEANUTILS-396) Forced setting of nested properties
Forced setting of nested properties --- Key: BEANUTILS-396 URL: https://issues.apache.org/jira/browse/BEANUTILS-396 Project: Commons BeanUtils Issue Type: Wish Components: Bean / Property Utils Affects Versions: 1.8.3 Environment: Ubuntu Reporter: tinghui wang Priority: Minor If the Bean has a Non-Primitiv field and this field has not been instantiated, it's impossible to set nested properties (the properties of the field). Needs a method just like BeanUtil#setPropertyForced(...) of jodd http://jodd.org/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[
https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070559#comment-13070559
]
Gary D. Gregory edited comment on CODEC-125 at 7/25/11 3:44 PM:
For me it looks like this test:
{noformat}
java.lang.AssertionError: language predicted for name 'Renault' is wrong: []
should contain 'french'
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.commons.codec.language.bm.LanguageGuessingTest.testLanguageGuessing(LanguageGuessingTest.java:84)
{noformat}
Fails because this bm.Lang method:
{code:java}
public Set guessLanguages(String text)
{
text = text.toLowerCase(); // todo: locale?
//System.out.println("Testing text: '" + text + "'");
Set langs = new HashSet(languages.getLanguages());
for(LangRule rule : rules)
{
if(rule.matches(text))
{
//System.out.println("Rule " + rule.pattern + " matches " +
text);
if(rule.acceptOnMatch) {
//System.out.println("Retaining " + rule.languages);
langs.retainAll(rule.languages);
}
else {
//System.out.println("Removing " + rule.languages);
langs.removeAll(rule.languages);
}
//System.out.println("Current languages: " + langs);
}
else
{
//System.out.println("Rule " + rule.pattern + " does not match
" + text);
}
}
return langs;
}
{code}
Return an empty set. It first add, then removes values in the loop and the set
finishes empty.
Could rule order be an issue. A difference in RE interpretation between Java 5
and 6? I am on 6.
was (Author: garydgregory):
For me it looks like this test:
java.lang.AssertionError: language predicted for name 'Renault' is wrong: []
should contain 'french'
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.commons.codec.language.bm.LanguageGuessingTest.testLanguageGuessing(LanguageGuessingTest.java:84)
Fails because this bm.Lang method:
public Set guessLanguages(String text)
{
text = text.toLowerCase(); // todo: locale?
//System.out.println("Testing text: '" + text + "'");
Set langs = new HashSet(languages.getLanguages());
for(LangRule rule : rules)
{
if(rule.matches(text))
{
//System.out.println("Rule " + rule.pattern + " matches " +
text);
if(rule.acceptOnMatch) {
//System.out.println("Retaining " + rule.languages);
langs.retainAll(rule.languages);
}
else {
//System.out.println("Removing " + rule.languages);
langs.removeAll(rule.languages);
}
//System.out.println("Current languages: " + langs);
}
else
{
//System.out.println("Rule " + rule.pattern + " does not match
" + text);
}
}
return langs;
}
Return an empty set. It first add, then removes values in the loop and the set
finishes empty.
Could rule order be an issue. A difference in RE interpretation between Java 5
and 6? I am on 6.
> Implement a Beider-Morse phonetic matching codec
>
>
> Key: CODEC-125
> URL: https://issues.apache.org/jira/browse/CODEC-125
> Project: Commons Codec
> Issue Type: New Feature
>Reporter: Matthew Pocock
>Priority: Minor
> Attachments: bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch,
> bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch
>
>
> I have implemented Beider Morse Phonetic Matching as a codec against the
> commons-codec svn trunk. I would like to contribute this to commons-codec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[
https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070559#comment-13070559
]
Gary D. Gregory commented on CODEC-125:
---
For me it looks like this test:
java.lang.AssertionError: language predicted for name 'Renault' is wrong: []
should contain 'french'
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.commons.codec.language.bm.LanguageGuessingTest.testLanguageGuessing(LanguageGuessingTest.java:84)
Fails because this bm.Lang method:
public Set guessLanguages(String text)
{
text = text.toLowerCase(); // todo: locale?
//System.out.println("Testing text: '" + text + "'");
Set langs = new HashSet(languages.getLanguages());
for(LangRule rule : rules)
{
if(rule.matches(text))
{
//System.out.println("Rule " + rule.pattern + " matches " +
text);
if(rule.acceptOnMatch) {
//System.out.println("Retaining " + rule.languages);
langs.retainAll(rule.languages);
}
else {
//System.out.println("Removing " + rule.languages);
langs.removeAll(rule.languages);
}
//System.out.println("Current languages: " + langs);
}
else
{
//System.out.println("Rule " + rule.pattern + " does not match
" + text);
}
}
return langs;
}
Return an empty set. It first add, then removes values in the loop and the set
finishes empty.
Could rule order be an issue. A difference in RE interpretation between Java 5
and 6? I am on 6.
> Implement a Beider-Morse phonetic matching codec
>
>
> Key: CODEC-125
> URL: https://issues.apache.org/jira/browse/CODEC-125
> Project: Commons Codec
> Issue Type: New Feature
>Reporter: Matthew Pocock
>Priority: Minor
> Attachments: bm-gg.diff, bmpm.patch, bmpm.patch, bmpm.patch,
> bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch, bmpm.patch
>
>
> I have implemented Beider Morse Phonetic Matching as a codec against the
> commons-codec svn trunk. I would like to contribute this to commons-codec.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-358) RamFileRandomAccessContent.close() does *NOT* call RamFileObject.close().
[
https://issues.apache.org/jira/browse/VFS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miroslav Pokorny updated VFS-358:
-
Summary: RamFileRandomAccessContent.close() does *NOT* call
RamFileObject.close(). (was: RamFileRandomAccessContent.close() does call
RamFileObject.close().)
> RamFileRandomAccessContent.close() does *NOT* call RamFileObject.close().
> -
>
> Key: VFS-358
> URL: https://issues.apache.org/jira/browse/VFS-358
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Miroslav Pokorny
>
> The problem manifests itself if one uses RandomAccessContent from a
> FileObject which is from ram://. Closing any stream from the RAC does not
> cleanup some counters which means future calls to FileObject.isContentOpen()
> return true which is wrong because the RAC.close().
> The fix to RamFileRandomAccessContent.close() is a simple one liner.
> /*
> * (non-Javadoc)
> *
> * @see org.apache.commons.vfs.RandomAccessContent#close()
> */
> @Override
> public void close() throws IOException {
> // do not try and call rafis.close() which does nothing but call this
> method.
> this.file.close();
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-150) Add support for writing Zip64 entries in ZipArchiveOutputStream
Add support for writing Zip64 entries in ZipArchiveOutputStream --- Key: COMPRESS-150 URL: https://issues.apache.org/jira/browse/COMPRESS-150 Project: Commons Compress Issue Type: Sub-task Reporter: Stefan Bodewig Assignee: Stefan Bodewig This should happen transparently if the entry's uncompressed or even compressed size exceeds 0x. Write correct markers in LFH and CD, write eight byte length in DD (if present) when entry used zip64, write zip64 extra fields if needed, write zip64 CD records if any entry uses zip64 or any offset exceeds 0x. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-149) Support reading of ZIP64 files in ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-149: Assignee: Stefan Bodewig > Support reading of ZIP64 files in ZipFile > - > > Key: COMPRESS-149 > URL: https://issues.apache.org/jira/browse/COMPRESS-149 > Project: Commons Compress > Issue Type: Sub-task > Components: Archivers >Reporter: Stefan Bodewig >Assignee: Stefan Bodewig > Fix For: 1.3 > > > Will need support for reading the new central directory structure as well as > everything that ZipArchiveInputStream does. > It may turn out that parsing of zip extra fields needs to be special cased > for the Zip64 field as the CD data cannot be reliably parsed from the raw > bytes without knowing which fields in the CD have been set to 0x. > Given that the zip64 extra field is a very special one for the format, this > may just be OK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-149) Support reading of ZIP64 files in ZipFile
Support reading of ZIP64 files in ZipFile - Key: COMPRESS-149 URL: https://issues.apache.org/jira/browse/COMPRESS-149 Project: Commons Compress Issue Type: Sub-task Reporter: Stefan Bodewig Will need support for reading the new central directory structure as well as everything that ZipArchiveInputStream does. It may turn out that parsing of zip extra fields needs to be special cased for the Zip64 field as the CD data cannot be reliably parsed from the raw bytes without knowing which fields in the CD have been set to 0x. Given that the zip64 extra field is a very special one for the format, this may just be OK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-148) Support reading of ZIP64 files in ZipArchiveInputStream
Support reading of ZIP64 files in ZipArchiveInputStream --- Key: COMPRESS-148 URL: https://issues.apache.org/jira/browse/COMPRESS-148 Project: Commons Compress Issue Type: Sub-task Reporter: Stefan Bodewig Assignee: Stefan Bodewig This will be by far the easiest part, will likely "only" need to detect Zip64 is used and use the extra field or 8byte length from data descriptor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-129) "java.io.EOFException: Truncated ZIP entry: "- while extracting a zip file that contains a entry which lager than 2 GB (Integer#MAX_VALUE)
[ https://issues.apache.org/jira/browse/COMPRESS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070406#comment-13070406 ] Stefan Bodewig commented on COMPRESS-129: - should be fixed with svn revision 1150608 of the zip64 branch, will resolve this issue once the branch is merged to trunk > "java.io.EOFException: Truncated ZIP entry: "- while extracting a > zip file that contains a entry which lager than 2 GB (Integer#MAX_VALUE) > -- > > Key: COMPRESS-129 > URL: https://issues.apache.org/jira/browse/COMPRESS-129 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.1 > Environment: Ubuntu 10; java 6 of sun >Reporter: tinghui wang > Fix For: 1.3 > > > Issue: > "java.io.EOFException: Truncated ZIP entry: " will be threw while > extracting a zip file that contains a entry with size larger than > Integer#MAX_VALUE bytes (about 2 GB). After the big entry has been read, then > try to get next entry by calling ZipArchiveInputStream#getNextZipEntry(), and > it throws that EOFException. > Cause: > before getting next zip entry, ZipArchiveInputStream tries to close the > current entry and in the close- method it use the field "bytesReadFromStream" > to ensure all entry bytes are read, however the field "bytesReadFromStream" > is a integer, that means it is already overflowed and it leads to a false > ensure result. > Solution suggestion: > instead integer using long for "bytesReadFromStream" and possibly for > "readBytesOfEntry" too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070392#comment-13070392
]
Bogdan Drozdowski edited comment on NET-408 at 7/25/11 9:37 AM:
The attached BCFTPSClient is the bouncycastle-based FTPSClient. Unfortunately,
it doesn't work for me (still "session not reused" error). Apparently, the
notifySessionID doesn't make the TlsClient use this session ID (or I'm doing
something wrong).
The code is a mess - some lines just commented-out, many now-useless methods
not removed, active-only mode supported. I didn't clean it up, because it
doesn't work anyway (for me). If you like it, you can use it. If it works for
you, let us know. Compile against "bcprov-jdk16-XXX.jar".
was (Author: bogdro):
This is the bouncycastle-based FTPSClient. Unfortunately, it doesn't work
for me (still "session not reused" error). Apparently, the notifySessionID
doesn't make the TlsClient use this session ID (or I'm doing something wrong).
The code is a mess - some lines just commented-out, many now-useless methods
not removed, active-only mode supported. I didn't clean it up, because it
doesn't work anyway (for me). If you like it, you can use it. If it works for
you, let us know. Compile against "bcprov-jdk16-XXX.jar".
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, PTFTPSClient.java, ftpes.jpg,
> proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Drozdowski updated NET-408:
--
Attachment: PTFTPSClient.java
The attached PTFTPSClient is the PureTLS-based FTPSClient. It uses the
host/port pair (whatever provided, just use unique for each control connection
and the control connection's host/port for data connections) to identify
connections.
It doesn't work for me (I get "Not a PrintableString or IA5String" exceptions),
but it may be my server's certificate's fault, so you may try it.
This code also is a mess - the host/port pairs (that identify sessions) are
hardcoded, some now-useless methods are not removed. It's more like some base
test code, to be rebuilt if works. If you like it, use it. If it works for you,
let us know.
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, PTFTPSClient.java, ftpes.jpg,
> proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Drozdowski updated NET-408:
--
Attachment: BCFTPSClient.java
This is the bouncycastle-based FTPSClient. Unfortunately, it doesn't work for
me (still "session not reused" error). Apparently, the notifySessionID doesn't
make the TlsClient use this session ID (or I'm doing something wrong).
The code is a mess - some lines just commented-out, many now-useless methods
not removed, active-only mode supported. I didn't clean it up, because it
doesn't work anyway (for me). If you like it, you can use it. If it works for
you, let us know. Compile against "bcprov-jdk16-XXX.jar".
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COMPRESS-128) Should close() methods check for System.in before calling close?
[ https://issues.apache.org/jira/browse/COMPRESS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-128: Fix Version/s: (was: 1.2) 2.0 > Should close() methods check for System.in before calling close? > > > Key: COMPRESS-128 > URL: https://issues.apache.org/jira/browse/COMPRESS-128 > Project: Commons Compress > Issue Type: Improvement >Reporter: Sebb > Fix For: 2.0 > > > The BZip2CompressorInput close method checks whether the input is equal to > System.in and skips the close call if so. > Should this be applied to all the ArchiveInput classes as well? > Probably does no harm. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
[
https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070358#comment-13070358
]
Luc Maisonobe commented on MATH-632:
I have tried to find again some external references from C++ standard and C99
standard. They seem to only specify behavior of == as a logical (a.real ==
b.real) && (a.imaginary == b.imaginary), which would lead to numbers with NaN
never been equal to anything, including themselves.
We don't use complex internally in [math] yet (at least I am not aware of it).
However, some existing users do (at least Arne seems to, as he asked for
several changes). Perhaps we should ask on the users list (not dev) for users
comments on this, as most users will not be aware of this Jira issue here.
We may need to use complex in [math] by ourselves for some algorithms we want
to implement. I see at least to difference use cases: eigen value decomposition
for non-symmetric matrices and root solvers. Do they use some standard
definition ?
> NaN: Method "equals" in Complex not consistent with "==" for "double"
> primitive type
>
>
> Key: MATH-632
> URL: https://issues.apache.org/jira/browse/MATH-632
> Project: Commons Math
> Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
> Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB)); // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with
> primitive "Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"),
> i.e. it is "correct" that assertion (1) is false. Do we want "Complex" to
> conform with this or with the inconsistent behaviour of "Double"?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
