case sensitive filenames

[Roedy Green]

Is there an easy way to find out if the file system you are running
under uses case-sensitive file names?
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Arne Vajhøj]

Is there an easy way to find out if the file system you are running
under uses case-sensitive file names?

Try:

public static boolean isFCS() {
return (new File("A")).equals(new File("a"));
}

Arne

 

[Andreas Leitgeb]

Is there an easy way to find out if the file system you are running
under uses case-sensitive file names?

Are you aware, that this depends on the specific directory?

E.g. on unix you may have a vfat-fs mounted to some mount-point.
inside: case-insensitive - outside: case-sensitive.

PS: no, I don't know of any safe test. Even if there was one,
by the time you act based on that knowledge, it may already
be out of date...

PPS: What would you want it for? (I can imagine some usecases,
myself. I just ask for your specific motivation.)

 

[Andrew Thompson]

On Jan 12, 10:01 pm, Andreas Leitgeb <[email protected]>
wrote:
....

PPS: What would you want it for?  (I can imagine some usecases,
  myself. I just ask for your specific motivation.)

A very good question (and one that goes too
often unasked).

 

[Roedy Green]

Are you aware, that this depends on the specific directory?

E.g. on unix you may have a vfat-fs mounted to some mount-point.
inside: case-insensitive - outside: case-sensitive.

Ouch. That is bad news. I need to know on a file by file basis then,
and obviously there will be nothing slick in Java to handle that.

I suppose I could try creating and upper case file with a unique name
and see if I can read it with the lower case name, once for each dir.

But now I think of it, it is probably ok just to presume case
sensitivity. If someone renames a file to have the same name with
different caps, they might not be upset if I treated it as if it were
a new file.
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Roedy Green]

PPS: What would you want it for? (I can imagine some usecases,
myself. I just ask for your specific motivation.)

It is funny how people are often defensive about that question, not
realizing the best way to solve a problem is often a route that
bypasses even needing its solution.
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Roedy Green]

PPS: What would you want it for? (I can imagine some usecases,
myself. I just ask for your specific motivation.)

Right now I have a compile time hard switch in untouch for filename
compare. It takes checksums of files and records the file name, then
later compares them. It needs to know if the current file is one for
which it has previously computed a checksum.

see http://mindprod.com/products1.html#UNTOUCH
--
Roedy Green Canadian Mind Products
http://mindprod.com
PM Steven Harper is fixated on the costs of implementing Kyoto, estimated as high as 1% of GDP.
However, he refuses to consider the costs of not implementing Kyoto which the
famous economist Nicholas Stern estimated at 5 to 20% of GDP

 

[Patricia Shanahan]

Right now I have a compile time hard switch in untouch for filename
compare. It takes checksums of files and records the file name, then
later compares them. It needs to know if the current file is one for
which it has previously computed a checksum.

see http://mindprod.com/products1.html#UNTOUCH

Symbolic links can also lead to distinct file names for the same file.
Perhaps you should compare canonical File object representations of the
file names, rather than directly comparing file names?

Patricia

 

[angrybaldguy]

Symbolic links can also lead to distinct file names for the same file.
Perhaps you should compare canonical File object representations of the
file names, rather than directly comparing file names?

Patricia

Even that doesn't necessarily help. Hard links, on systems that
support them, imply that a file has *several* canonical names, all
equally-valid and none more canonical than the others.

-o

 

[Arne Vajhøj]

PS: no, I don't know of any safe test. Even if there was one,
by the time you act based on that knowledge, it may already
be out of date...

I would guess many people could live with that risk.

Arne

 

[Arne Vajhøj]

Ouch. That is bad news. I need to know on a file by file basis then,
and obviously there will be nothing slick in Java to handle that.

I suppose I could try creating and upper case file with a unique name
and see if I can read it with the lower case name, once for each dir.

File equals should be enough without actually creating any files.

Arne

 

[Mike Schilling]

File equals should be enough without actually creating any files.

I suspect not. If a Linux machine has, say, both native
case-sensitive filesystems and case-insensitive filesystems mounted
via SAMBA, I'd be surprised if File.equals() went as far as figuring
out which filesystem the path would be on, rather than applying the
Linux default of "case sensitive". (Though not having such a
machine, I can't test it.)

 

[Andreas Leitgeb]

I would guess many people could live with that risk.

Depends. In most cases: yes.

If it were security-relevant, things may be different.

 

[Andreas Leitgeb]

I suspect not. If a Linux machine has, say, both native
case-sensitive filesystems and case-insensitive filesystems mounted
via SAMBA, ...

Having peeked into src.zip...
File.equals calls File.compareTo which calls fs.compare where
fs is a static reference of type FileSystem, initialized from
FileSystem.getFileSystem(), which is a native method.

The comments (javadoc) say:
* Return the FileSystem object representing this platform's
* local filesystem.

Which appears to imply, that any mounted alien filesystems are
not accounted for. But, if anyone had e.g. a vfat root-filesystem
under Linux (with just the special dirs (/dev) mounted differently),
I wonder if Java's default FileSystem implementation would account
for this.

The gist is, that File.equals may be a good heuristic, but not
truely reliable. Applications should avoid depending on that
distinction in the first place.

 

[Nigel Wade]

Having peeked into src.zip...
File.equals calls File.compareTo which calls fs.compare where
fs is a static reference of type FileSystem, initialized from
FileSystem.getFileSystem(), which is a native method.

The comments (javadoc) say:
* Return the FileSystem object representing this platform's
* local filesystem.

Which appears to imply, that any mounted alien filesystems are
not accounted for. But, if anyone had e.g. a vfat root-filesystem
under Linux (with just the special dirs (/dev) mounted differently),
I wonder if Java's default FileSystem implementation would account
for this.

It doesn't.

$ mount
/dev/sda on /media/disk type vfat

$ java FileEquals /media/disk/a /media/disk/A
false
$ java FileEquals /media/disk/a /media/disk/a
true

FileEquals just outputs the result of File.equals for the two arguments.

 

[Tom Anderson]

Even that doesn't necessarily help. Hard links, on systems that support
them, imply that a file has *several* canonical names, all equally-valid
and none more canonical than the others.

It doesn't solve the problem completely, but i wouldn't say it doesn't
help - using a canonical path will deal with case-insensitivity and
symlinks, leaving hardlinks the only stumbling-block. And since Roedy is
on windows, IIRC, not one that will trip him up very often!

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.

tom

[1] Case-insensitive in that it preserves case, but ignores it for the
purposes of deciding whether a name matches a file.

--
But in natural sciences whose conclusions are true and necessary and
have nothing to do with human will, one must take care not to place
oneself in the defence of error; for here a thousand Demostheneses and
a thousand Aristotles would be left in the lurch by every mediocre wit
who happened to hit upon the truth for himself. -- Galileo

 

[Wojtek]

Tom Anderson wrote :

And since Roedy is on windows, IIRC, not one that will trip him up very
often!

Cross-platform application? His customers may not like it...

 

[Tom Anderson]

Tom Anderson wrote :


Cross-platform application? His customers may not like it...

I don't think unix users expect tools to treat two files which are
hardlinked to the same data as being the same file, so i don't think it
would make them unhappy.

tom

--
But in natural sciences whose conclusions are true and necessary and
have nothing to do with human will, one must take care not to place
oneself in the defence of error; for here a thousand Demostheneses and
a thousand Aristotles would be left in the lurch by every mediocre wit
who happened to hit upon the truth for himself. -- Galileo

 

[Nigel Wade]

Even that doesn't necessarily help. Hard links, on systems that support
them, imply that a file has *several* canonical names, all equally-valid
and none more canonical than the others.

It doesn't solve the problem completely, but i wouldn't say it doesn't
help - using a canonical path will deal with case-insensitivity and
symlinks, leaving hardlinks the only stumbling-block. And since Roedy is
on windows, IIRC, not one that will trip him up very often!

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

 

[Thomas Kellerer]

Eric Sosman wrote on 13.01.2009 17:48:

When do you suppose we'll get a font-sensitive file system?
Wouldn't it be nice if the editor saved the old version of Foo.java
not as Foo.java~ but as <i>Foo.java</i>?

I wouldn't put something like that into the filesystem. In my opinion that's the
responsibility of the file manager.

With TotalCommander I can at least display those files in grey rather than with
a black color

Thomas