File.toUrl, is this a bug? the problem, fix

Marilen Corciovei marilen.corciovei@nemesisit.ro
Tue Apr 15 14:47:00 GMT 2003


Beside that there is an ununiform handling of the fileName in the
FileInputStream: the constructor with a String parameter does not use
the File class so if any code is added for fixing this problem something
has to be changed here also (and in the FileOutputStream also). This
quick fix should be to change:

fd = new FileDescriptor (path, (append
    ? FileDescriptor.APPEND
    : FileDescriptor.WRITE)); to

fd = new FileDescriptor (new File(path).getPath(), (append
    ? FileDescriptor.APPEND
    : FileDescriptor.WRITE));

I that way the normalizing code will be in the File class and only
there.

The following code is a quick fix for this problem in the function
normalizePath(). This also fixes another issue: Sun jvm returns for
File("//c:/test").getPath() "c:\test" while gcj returned "\\c:\test".

    if(separatorChar == '\\'){
        if(p.charAt(0)== '\\' && p.charAt(1)!= '\\' && p.charAt(2)==':')
            return p.substring(1);
        if(p.charAt(0)== '\\' && p.charAt(1)== '\\' && p.charAt(3)==':')
            return p.substring(2);
    }
    return p;

Thanks, Len

On Tue, 2003-04-15 at 09:28, Ranjit Mathew wrote: 
> > sorry I did not mentioned that earlyer. The File.toURL() and
> > URL.getFile() return the same results as in the sun jvm. I tested that
> > already. If compliancy is wanted then the changes could be done in the
> 
> To summarise:
> 
>     'new File( "c:\\temp\\foo.txt").toURL( )' returns 
>     the URL object for "file:/c:/temp/foo.txt"
> 
>     This URL's getFile( ) returns "/c:/temp/foo.txt".
> 
>     'new File( "/c:/temp/foo.txt").toString( )' gives
>     "c:\temp\t.txt" with Sun's JRE but gives "\c:\temp\t.txt"
>     with GCJ, which causes problems later.
> 
> Some time back, I had submitted a patch for fixing more of
> filenames handling code on GCJ for Win32:
> 
>     http://gcc.gnu.org/ml/java-patches/2003-q1/msg00636.html
> 
> but admittedly that still does not handle this case. :-(
> (The patch has not been reviewed yet.)
> 
> The problem is that going strictly by the JDK API docs, I
> do not think the path "/c:/temp/t.txt" is valid but apparently
> it does seem to work with Sun's JRE. (Even File.isAbsolute( )
> returns true with this path with Sun's JRE, though it should not, 
> going strictly by the docs...)
> 
> ~uggghhh~ I guess we will have to fix this special case. I
> wonder how many other special cases we will have to handle
> before we can claim 100% compliance with the reference
> implementation...
> 
> 
> > FileInputStream.java class. (In the sun jvm there is a
> > FileSystem.normalize method called) maybe something similar is needed.
> 
> Interesting. There's this public (abstract) class java.io.FileSystem
> but it is not documented by the main JDK API docs, though I could
> find documentation for it, for example, here:
> 
>     http://www.erights.org/javadoc/java/io/FileSystem.html
> 
> Can anyone shed any light on this? libgcj does not have this
> class and its concrete implementations - should we have it?
> 
> Ranjit. 


Marilen Aretius Corciovei

Technical Manager, Nemesis IT

marilen.corciovei@nemesisit.ro
http://www.nemesisit.ro

+40-721253015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix.patch
Type: text/x-patch
Size: 2039 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030415/c1799c9f/attachment.bin>


More information about the Java mailing list