[jira] Issue Comment Edited: (COMPRESS-124) Unable to extract a TAR file that contains sparse entries
[ https://issues.apache.org/jira/browse/COMPRESS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971567#action_12971567 ] Patrick Dreyer edited comment on COMPRESS-124 at 12/15/10 2:36 AM: --- Including not only the source but as well the documentation and changes.xml Unfortunately, I was not able to generate a test TAR archive containing sparse files, even invoking GNU Tar with "--sparse" and all the TAR archives I have with such sparse files, contain information I'm not allowed disclose. If someone is able to generate a TAR archive containing sparse files and provide such, pleas let me know so I can include the necessary unit tests. was (Author: patrickdreyer): Including not only the source but as well the documentation and changes.xml > Unable to extract a TAR file that contains sparse entries > - > > Key: COMPRESS-124 > URL: https://issues.apache.org/jira/browse/COMPRESS-124 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.1, 1.2 > Environment: Platform independent. However, I'm currently using > Window 7 Enterprise. >Reporter: Patrick Dreyer > Fix For: 1.2 > > Attachments: gnuSparseFile.patch > > > Good news first: I already have the patch ready for that. > I got several TAR files which I could not extract with any of the existing > Java implementations, but I could extract all those TAR files successfully > with GNU tar. > It turned out that all the failing TAR files contained so called sparse > files. Investigating the source code of all existing Java TAR implementations > showed me that none of them even recognizes the existence of GNU sparse > entries. > Actually, I don't need to process one of the contained sparse files and I'm > happy if I'm at least able to correctly untar all the non-sparsed files. > Thus, it would be sufficient recognizing sparse files without the need to > correctly un-sparse them while extracting. As long as all non-sparsed files > get extracted correctly, I'm fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COMPRESS-124) Unable to extract a TAR file that contains sparse entries
[ https://issues.apache.org/jira/browse/COMPRESS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Dreyer updated COMPRESS-124: Attachment: gnuSparseFile.patch Including not only the source but as well the documentation and changes.xml > Unable to extract a TAR file that contains sparse entries > - > > Key: COMPRESS-124 > URL: https://issues.apache.org/jira/browse/COMPRESS-124 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers >Affects Versions: 1.1, 1.2 > Environment: Platform independent. However, I'm currently using > Window 7 Enterprise. >Reporter: Patrick Dreyer > Fix For: 1.2 > > Attachments: gnuSparseFile.patch > > > Good news first: I already have the patch ready for that. > I got several TAR files which I could not extract with any of the existing > Java implementations, but I could extract all those TAR files successfully > with GNU tar. > It turned out that all the failing TAR files contained so called sparse > files. Investigating the source code of all existing Java TAR implementations > showed me that none of them even recognizes the existence of GNU sparse > entries. > Actually, I don't need to process one of the contained sparse files and I'm > happy if I'm at least able to correctly untar all the non-sparsed files. > Thus, it would be sufficient recognizing sparse files without the need to > correctly un-sparse them while extracting. As long as all non-sparsed files > get extracted correctly, I'm fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COMPRESS-124) Unable to extract a TAR file that contains sparse entries
Unable to extract a TAR file that contains sparse entries - Key: COMPRESS-124 URL: https://issues.apache.org/jira/browse/COMPRESS-124 Project: Commons Compress Issue Type: New Feature Components: Archivers Affects Versions: 1.1, 1.2 Environment: Platform independent. However, I'm currently using Window 7 Enterprise. Reporter: Patrick Dreyer Fix For: 1.2 Good news first: I already have the patch ready for that. I got several TAR files which I could not extract with any of the existing Java implementations, but I could extract all those TAR files successfully with GNU tar. It turned out that all the failing TAR files contained so called sparse files. Investigating the source code of all existing Java TAR implementations showed me that none of them even recognizes the existence of GNU sparse entries. Actually, I don't need to process one of the contained sparse files and I'm happy if I'm at least able to correctly untar all the non-sparsed files. Thus, it would be sufficient recognizing sparse files without the need to correctly un-sparse them while extracting. As long as all non-sparsed files get extracted correctly, I'm fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-325) Bad handling of hashs (#) in file names when walking a file tree using findFiles()
[
https://issues.apache.org/jira/browse/VFS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry Reeve updated VFS-325:
Attachment: PATCHB-vfs-325.tar
Revised patch based on Joerg's feedback.
> Bad handling of hashs (#) in file names when walking a file tree using
> findFiles()
> --
>
> Key: VFS-325
> URL: https://issues.apache.org/jira/browse/VFS-325
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 1.0, 1.1, 2.0
> Environment: Windows Seven, JDK 1.6 64 bit
>Reporter: Nicolas Guillaumin
> Attachments: PATCH-vfs-325.tar, PATCHB-vfs-325.tar
>
>
> Consider a local directory tree containing files with hashs in their name,
> such as {{test-hash-#.txt}}.
> When walking the tree using FileObject.findFiles(), the file is correctly
> found and returned, but it's URL is truncated to the #: {{test-hash-}}
> * Calling file.getURL().toString() returns {{file://my/dir/test-hash-}}
> * Calling file.toString() returns the correct URL
> {{file://my/dir/test-hash-#.txt}}
> * For the sake of testing, calling new
> URL("http://my/file/with/hash-#.txt";).toString() returns
> {{http://my/file/with/hash-#.txt}} (It's not an java.net.URL problem)
> I think file.getURL().toString() should return {{test-hash-#.txt}}, otherwise
> caller have to rely on file.toString() to retrieve the URL of the file, which
> is probably bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CONFIGURATION-431) Code caused NullPointer error in XMLConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971416#action_12971416
]
Oliver Heger commented on CONFIGURATION-431:
There are probably other classes which have the same issue. I think the problem
is caused by the different constructors of AbstractFileConfiguration which
already load the configuration file and call non-final methods which are
overridden in subclasses.
A safe solution would be to deprecate all these constructors except for the
standard constructor. Client code should create a configuration instance by
calling the default constructor and then load the data in a second step.
WDYT, would this solve the problem?
> Code caused NullPointer error in XMLConfiguration
> -
>
> Key: CONFIGURATION-431
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-431
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: gentboy
>Priority: Critical
>
> In class XMLConfiguration there is a code structure like below:
> public static void main(String[] args) {
> new B();
> }
> static abstract class A {
> A(){
> print();
> }
> abstract void print();
> }
>
> static class B extends A{
> String s = new String("asdf");
> B(){
> super();
> }
>
> void print(){
> System.out.println(s);
> }
> }
> While in B.print the field s is actually not initialized because it is called
> from the super() method.
> In XMLConfiguration the not properly initialized field is registeredEntities,
> which will defenitly cause nullpointer in some case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CONFIGURATION-431) Code caused NullPointer error in XMLConfiguration
Code caused NullPointer error in XMLConfiguration
-
Key: CONFIGURATION-431
URL: https://issues.apache.org/jira/browse/CONFIGURATION-431
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.6
Reporter: gentboy
Priority: Critical
In class XMLConfiguration there is a code structure like below:
public static void main(String[] args) {
new B();
}
static abstract class A {
A(){
print();
}
abstract void print();
}
static class B extends A{
String s = new String("asdf");
B(){
super();
}
void print(){
System.out.println(s);
}
}
While in B.print the field s is actually not initialized because it is called
from the super() method.
In XMLConfiguration the not properly initialized field is registeredEntities,
which will defenitly cause nullpointer in some case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (EMAIL-102) HtmlEmail embed toLowerCase bug
HtmlEmail embed toLowerCase bug --- Key: EMAIL-102 URL: https://issues.apache.org/jira/browse/EMAIL-102 Project: Commons Email Issue Type: Bug Affects Versions: 1.2 Environment: Windows XP, Solaris and Turkish Regional Environment Reporter: Okan Özeren Priority: Minor When I embed an image to my html email object, if randomAlphabetic (on this line HtmlEmail.java:325) method brought uppercase 'I' character, at the this time toLowerCase method convert it to lowercase Turkish 'ı' character. I think, toLowerCase brougt lowercase 'ı' character when regional settings up to Turkish. In that case, this header variable expose to mime encoding process and set as like "cid:=C4=B1glhuooecb" (=C4=B1 is lowercase 'ı' character) and the mail clients does not show this embedded image. Maybe, toLowerCase method use by passing English Locale parameters then this must work correctly like this "toLowerCase(Locale.ENGLISH);". Best regards, Okan Özeren. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
