case sensitive filenames

T

Tom Anderson

Tom said:
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.

tom
 
N

Nigel Wade

Tom said:
Tom said:
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.
 
M

Martin Gregorie

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.

- however, Nautilus and the gedit both think test.txt and Test.txt are
the same file name.

In summary, I'd agree that Linux (or at least the rather old Fedora 1) is
broken, but not for the reasons you give. I'd say its broken because its
command line behavior isn't consistent in the way it deals with vfat file
names.

I can't comment about Java on vfat file names - Java isn't installed on
that box and its so slow that I have no intention of installing Java on
it. The box is an ancient K6/266 with 394 MB ram. It runs Fedora 1 almost
as slowly as XP runs on a laptop with 766MHz and 128 MB RAM - this is
unsurprising as F1 minimum hardware is stated as 400 MHz plus 256 MB RAM.
 
T

Tom Anderson

...

Also, the primary question is self-reported equality of File objects,
not String equality of their names. Are those always the same?

Good question. File equality can't be equivalent to equality of canonical
paths, since computing a canonical path can throw an IOException, and
computing equality can't.

The docs say:

Tests this abstract pathname for equality with the given object. Returns
true if and only if the argument is not null and is an abstract pathname
that denotes the same file or directory as this abstract pathname.
Whether or not two abstract pathnames are equal depends upon the
underlying system. On UNIX systems, alphabetic case is significant in
comparing pathnames; on Microsoft Windows systems it is not.

This specification is incoherent, given the existence of VFAT and HFS+ on
unix machines.

Furthermore, i strongly suspect that it's simply a lie. The beginning of
the description sounds like something that only getCanonicalPath could
implement, and i can't believe equals is using that. A small test:

import java.io.* ;
public class FileEquals {
public static void main(String[] args) throws IOException {
File a = new File(args[0]) ;
File b = new File(args[1]) ;
System.out.println("File.equals: " + a.equals(b)) ;
System.out.println("File.getCanonicalPath.equals: "
+ a.getCanonicalPath().equals(b.getCanonicalPath())) ;
}
}

Hooke:~/Temp tom$ uname -a
Darwin Hooke.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
Hooke:~/Temp tom$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-275)
Java HotSpot(TM) Client VM (build 1.5.0_16-132, mixed mode, sharing)

Hooke:~/Temp tom$ java FileEquals FileEquals.java FileEquals.java
File.equals: true
File.getCanonicalPath.equals: true
Hooke:~/Temp tom$ java FileEquals FileEquals.java FileEquals.JAVA
File.equals: false
File.getCanonicalPath.equals: true
Hooke:~/Temp tom$ ln -s FileEquals.java FileEquals.link
Hooke:~/Temp tom$ java FileEquals FileEquals.java FileEquals.link
File.equals: false
File.getCanonicalPath.equals: true

According to the javadoc, all three of those should be equal.

tom
 
T

Tom Anderson

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
some kind of image data.

I pine for the good old days of the Real Mac, where all this information
was right where it belongs, in a metadata field in the filesystem. No
extensions, no sniffing needed. Sigh.
- however, Nautilus and the gedit both think test.txt and Test.txt are
the same file name.

In summary, I'd agree that Linux (or at least the rather old Fedora 1) is
broken, but not for the reasons you give. I'd say its broken because its
command line behavior isn't consistent in the way it deals with vfat file
names.

I'd disagree - i think it's VFAT that's broken!

tom
 
T

Tom Anderson

Tom said:
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 closed!

I suppose that Sun assumed that unix would always be using a
case-sensitive filesystem, and didn't bother writing this code properly.
Perhaps they should borrow Apple's patch!

tom
 
M

Martin Gregorie

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 some kind of image data.

I pine for the good old days of the Real Mac, where all this information
was right where it belongs, in a metadata field in the filesystem. No
extensions, no sniffing needed. Sigh.
- however, Nautilus and the gedit both think test.txt and Test.txt are
the same file name.

In summary, I'd agree that Linux (or at least the rather old Fedora 1)
is broken, but not for the reasons you give. I'd say its broken because
its command line behavior isn't consistent in the way it deals with
vfat file names.

I'd disagree - i think it's VFAT that's broken!
Vfat has a lot of problems, mostly inherited from MS and ranging from
'longname.ext' vs '7-CHARS~.EXT' to the absolute 4GB file size limit.

As the rest of Linux is case-sensitive I'd expect it to be case-sensitive
for vfat too, but that's another issue. Bash's case-agnosticism if you
type the full name vs case sensitivity in name completion is just crap.

BTW, if you want to see case insensitivity done properly, take a look at
OS-9. File system names can be entered in mixed case. The case is
preserved and used to sort directory listings but is otherwise ignored.
The result is that you can use case to distinguish directories (an OS-9
convention) or affect directory listing order, but you can always type
commands in lower case unless, of course, you're creating a file or
directory name that you want to capitalise.
 
W

Wojtek

Tom Anderson wrote :
I pine for the good old days of the Real Mac, where all this information was
right where it belongs, in a metadata field in the filesystem. No extensions,
no sniffing needed.

And OS/2
 
L

Lew

Tom said:
Interesting. In Colchester, we spell it Lew's way.

"phase" and "faze" are two different words with entirely different meanings.
I am left-pondian, but I was not aware of a different usage in the Queen's
English.

<http://dictionary.cambridge.org/define.asp?key=28245>
<http://dictionary.cambridge.org/define.asp?key=59319>
agrees.

<http://www.dictionary.co.uk/browse.aspx?word=faze>
says to "See Feeze",
<http://www.dictionary.co.uk/browse.aspx?word=feeze>
which has a similar meaning to what I know.
<http://www.dictionary.co.uk/browse.aspx?word=phase>
doesn't even list a verb meaning.

But perhaps you are unfazed by this evidence.
<http://dictionary.cambridge.org/define.asp?key=86490>
 
L

Lew

Tom said:
Shocking! Lew, you're the last person i expected to have to say this to,
but: read the javadocs. They say:

Every pathname that denotes an existing file or directory has a unique
canonical form. Every pathname that denotes a nonexistent file or
directory also has a unique canonical form. The canonical form of the
pathname of a nonexistent file or directory may be different from the
canonical form of the same pathname after the file or directory is
created. Similarly, the canonical form of the pathname of an existing
file or directory may be different from the canonical form of the same
pathname after the file or directory is deleted.

Returns: The canonical pathname string denoting the same file or
directory as this abstract pathname

Two key things: whether a file exists or not *does* (or at least *can*)
matter, and the definition of the canonicalised path is "the canonical
pathname string *denoting the same file or directory* as this abstract
pathname" (my emphasis). That means that if a file or directory exists,
then all paths which refer to it map to the same canonical path. If it
doesn't, i don't think that bit can apply. Thus, my question is germane.

I stand corrected.
 
A

Andreas Leitgeb

Tom Anderson said:
I pine for the good old days of the Real Mac, where all this information
was right where it belongs, in a metadata field in the filesystem. No
extensions, no sniffing needed. Sigh.

r u serious?

That crap didn't even have an "Open with..."-feature, just as if for
each file there couldn't ever exist more than one app to deal with it...
 
A

Andreas Leitgeb

Tom Anderson said:
I suppose that Sun assumed that unix would always be using a
case-sensitive filesystem, and didn't bother writing this code properly.
Perhaps they should borrow Apple's patch!

From what I've gathered in this thread, macosx's usual filesystem is
case-insensitive, so I'd doubt that they had a special patch for vfat.
And I wouldn't want Java to assume general case-insensitivity on other
unices.
 
T

Tom Anderson

r u serious?

That crap didn't even have an "Open with..."-feature, just as if for
each file there couldn't ever exist more than one app to deal with it...

Wrong. It didn't have an 'open with' menu option, but context menus were
never the classi Mac way (unfortunately). You could drag a file onto any
suitable app to open it, and you could File > Open any suitable file from
within an app.

tom
 
T

Tom Anderson

From what I've gathered in this thread, macosx's usual filesystem is
case-insensitive, so I'd doubt that they had a special patch for vfat.

I meant a patch to the getCanonicalPath - unlike the java implementation
on linux, it gets it right in the presence of a case-insensitive
filesystem.
And I wouldn't want Java to assume general case-insensitivity on other
unices.

It's not so much a matter of assuming general case-insensitivity as being
prepared to handle it where it occurs. The Mac java implementation does
the right thing with both case-insensitive and-sensitive filesystems - it
would still work correctly on systems with only case-sensitive
filesystems.

tom
 
T

Tom Anderson

Vfat has a lot of problems, mostly inherited from MS and ranging from
'longname.ext' vs '7-CHARS~.EXT' to the absolute 4GB file size limit.

As the rest of Linux is case-sensitive I'd expect it to be case-sensitive
for vfat too, but that's another issue.

Yes, this is the really weird thing. AIUI, there's nothing
case-insensitive about the layout on disk, just the code that, under
windows, accesses that data. That means there was no particular reason to
make linux's VFAT implementation case-insensitive. So why did they? I
assume to make it more comfortable for windows users, but since it's made
it less comfortable for linux users, that seems like a strange decision.

Is there an option to mount VFAT volumes in a case-sensitive mode? The Mac
will do this for HFS+ now - although i think you have to specify it when
you create the filesystem, rather than as a mount option.

tom
 
A

Andreas Leitgeb

Tom Anderson said:
... The Mac java implementation does the right thing with
both case-insensitive and -sensitive filesystems

Ah ok, thanks. I stand informed :)
 
A

Andreas Leitgeb

Wrong. It didn't have an 'open with' menu option, but context menus were
never the classi Mac way (unfortunately).

At least, you seem to agree (by saying "unfortunately") to that it was bad
in that particular aspect (namely entries of the context menu).

PS: dragging icons with a touchpad sucks hard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Debugging regex 3
Browser news 4
almost equal strings 20
Regex Puzzle 5
Constellations 38
Smoothing 2
case sensitive file names 14
case strings 8

Members online

No members online now.

Forum statistics

Threads
473,754
Messages
2,569,521
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top