On Tue, 13 Jan 2009 23:53:19 +0000, Tom Anderson wrote:
On Tue, 13 Jan 2009, Martin Gregorie wrote:
On Tue, 13 Jan 2009 21:21:48 +0000, 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! :)
If its a bug. The Linux tin says its case sensitive. It matches the
description by being consistently case sensitive over its native filing
systems plus at least vfat.
Hang on, what actually is the case sensitivity under linux + vfat? If i
do:
I got that wrong: apologies. I have a dual boot system that gets used
about once a month if that and that mounts its Win95 partitions as vfat
partitions. Almost every time it gets booted I run Win95, not Linux,
because its only there to run a few legacy applications that don't have
Linux equivalents.
Anyway, I just booted it into Linus (Fedora Core 1) and found that it is
case-sensitive in vfat partitions - sort of:
- there's a file called a.txt in directory TEMP in my vfat temp
partition. 'cat a.txt' and 'cat A.txt' both list it: this is not
case sensitive.
- in this directory is a directory called 'Download'
'cd Download' and 'cd download' both work BUT bash command completion
requires the exact case to be supplied in the name stub.
- if I make files called 'test.ZIP' and 'test2.zip' then the command line
'ls' command colours 'test.ZIP' white (ordinary) and 'test2.zip' red
(compressed), so the 'ls' type recognition is case sensitive
- the Nautilus file manager, like the GIMP image editor both ignore the
extension entirely and look at the file contents: rename a JPEG file to
misnamed.txt and Nautilus shows an image thumbnail and launches an
image viewer if its selected. The GIMP handles it without comment.
These are not only case insensitive but extension-agnostic.
That's sometimes a very good idea, and sometimes not. I was trying to open
an XML document encoded in UTF-16LE earlier today. 'file' decided it was
was right where it belongs, in a metadata field in the filesystem. No
extensions, no sniffing needed. Sigh.