On 6/6/2013 1:02 PM, Michel Fortin wrote:
On 2013-06-06 17:27:28 +0000, Walter Bright <[email protected]> said:
That doesn't work for case sensitivity/insensitivity differences nor does it
work for drive letters like "C:" (which don't exist on Apple systems, hence
they can afford to dismiss them).
Have you never opened a local file in a windows web browser and took a look at
the URL? The drive letter is there.
file:///c:/path/to/the%20file.txt
The drive letter is simply the first part of the path on Windows.
I didn't know that, but that doesn't make it a canonical path. It just combines
the notion of url with a path.
But there's no getting around the fact that "File" and "file" are different
paths under Windows, and are the same under Linux.
Actually, it doesn't depend on Linux or Windows or OS X. It depends on the
filesystem used, be it FAT16, FAT32, NTFS, ext{1,2,3}, HFS+, Case-sensitive
HFS+, etc. If you assume a specific case sensitivity setting by looking at the
OS, that's a bug. You can mount NTFS and FAT on Linux or OS X, and Apple has
Case-sensitive HFS+ for OS X and its the default on iOS. Then there's the whole
issue about which locale to use for Unicode case-insensitive comparisons. I'd
bet that different filesystems choose different approaches to this tricky
problem.
So there's no way to normalize for case-sensitivity just by looking at a path or
a URL, even if you know on which OS you're on. If you want to know for sure
whether two paths are the same, or what is the normalized path, you need to ask
the filesystem at some point. Anything else is based on fragile assumptions.
It may be a bug, and I personally try to never depend on path code that is case
sensitive or not, but I bet there's a *lot* of code out there that makes those
assumptions.
BTW, Windows still has only erratic support for using / as path separators, even
in the system commands. Not even the "DIR" command can deal with it.
