java.io.File

Thu Jul 22 13:40:00 GMT 2004

Take the following with a grain of salt since I am not an expert in 
these matters.
On Windows using Sun 1.4.2_04 File.getAbsolutePath() will return:
 C:\some\path
for a path on a normal hard drive or on a networked drive
but for a CDROM drive (assume E: is cdrom drive) it returns:
 E:\\some\path
i.e. an extra backslash is inserted. (Tested Win2K, 1.4.2_04).
In my app I code around that anomaly. I don't know if that is a bug
or a feature in Sun's jvm on Windows.
I have not tested the equivalent using gcj and have no idea what
the spec says should happen.
Regards,
Heitzso
Jeroen Frijters wrote:
>Hi,
>>I just merged libgcj's Windows support in java.io.File to Classpath's
>java.io.File and I noticed two small bugs. Attached is a patch for
>gcc/libjava/java/io/File.java that adds support for "\c:" style paths to
>normalizePath.
>>The second issue is a bit subtle. The native Win32 implementation of
>getCanonicalPath, will resolve a relative file based on the current
>Win32 directory, not the user.dir Java system property. Here's what I
>ended up doing:
>> public String getCanonicalPath() throws IOException
> {
> // On Windows, getAbsolutePath might end up calling us, so we
> // have to special case that call to avoid infinite recursion.
> if (separatorChar == '\\' && path.length() == 2 &&
>	((path.charAt(0) >= 'a' && path.charAt(0) <= 'z') ||
>	 (path.charAt(0) >= 'A' && path.charAt(0) <= 'Z')) &&
>	path.charAt(1) == ':')
> {
>	return VMFile.toCanonicalForm(path);
> }
> // Call getAbsolutePath first to make sure that we do the
> // current directory handling, because the native code
> // may have a different idea of the current directory.
> return VMFile.toCanonicalForm(getAbsolutePath());
> }
>>Regards,
>Jeroen
>>