Tom Anderson wrote:
On Wed, 14 Jan 2009, Nigel Wade wrote:
Tom Anderson wrote:
On Tue, 13 Jan 2009, Nigel Wade wrote:
Tom Anderson wrote:
Also, it appears that getCanonicalPath deals with varying case-sensitivity
across the directory tree correctly - i'm on a Mac, which has a
case-insensitive HFS+ filesystem [1], and have a linux box mounted over
sftp, which has a case-sensitive filesystem of some sort. If i have a
foo.txt on both, getCanonicalPath correctly maps foo.TXT to foo.txt on the
Mac filesystem, and keeps it as foo.TXT on the linux.
It doesn't on Linux with VFAT filesystems. They remain resolutely
case-sensitive as far as File is concerned:
File.getCanonicalPath("/some/vfatpath/foo.txt") returns /some/vfatpath/foo.txt
File.getCanonicalPath("/some/vfatpath/FOO.txt") returns /some/vfatpath/FOO.txt
Interesting. But that's clearly a bug with linux, not java! :)
There is nothing wrong with Linux.
A highly debatable statement! :)
Outside of Java FOO.txt and foo.txt on a VFAT filesystem are the same
file. If you ask for the canonical path to foo.txt you get back foo.txt,
which is a perfectly valid path. If you ask for the path to FOO.txt you
get back FOO.txt which is also a perfectly valid path to the same file.
Both alternatives are valid, but they can't both be canonical (that's what
canonical means), and since getCanonicalPath is called getCanonicalPath, i
would expect it to return a name that is in some way canonical.
But, as i explain in my response to Lew, that only happens when the file
in question exists.
I see no justification for expecting to get back foo.txt when you ask
for FOO.txt. Why foo.txt and not, for example, Foo.txt or fOO.txt or
FOO.TXT all of which are equally valid responses? Why do you expect to
the lowercase filename to be returned?
I don't. I expect to get back the given name of the file referred to by
the path - if such a file exists. If it doesn't, i'm happy to get back a
path with the same capitaisation of the input.
That doesn't happen on Linux. If that is actually the meaning of "unique" in the
definition of getCanonicalPath() then the correct information is not returned.
If there is a bug I think it's in the JVM. The filesystem is doing what it's
supposed to do in that a reference to the file using any case is valid.
Performing an ls of the directory in question lists the file with the correct
mixed-case. So the JVM must not be interrogating the filesystem to get the
actual file name, I presume it is assuming that the filesystem is
case-sensitive so it doesn't need to. This is actually borne out by doing an
strace of the system calls:
lstat64("/media", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/media/disk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/media/disk/AbC", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
lstat64("/media", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/media/disk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/media/disk/abc", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
all the JVM does is lstat the path to see if it exists. The filesystem quite
correctly says that both names for the file exist since they are equally valid
for a FAT filesystem. The JVM makes no attempt to obtain the actual filename or
verify that the path is unique.
case-sensitive filesystem, and didn't bother writing this code properly.