Closed Bug 207305 Opened 21 years ago Closed 8 years ago

Mac OS X: file URLs are caps insensitive

Categories

(Core :: Networking, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: benc, Unassigned)

References

()

Details

STEPS:

open /etc/hosts file via URL bar (type: file:///etc/hosts)
access same file via a incorrect captalization (type: file///etc/hosts)

This behavior is a Mac OS-only.

The cause seems to be that there is some caps insensitivity built into the UNIX
layer:

% touch test
% touch TEST
% ls
test

Brade suggested that this might have been the case in Mac OS classic, and that
this is some kind of legacy behavior.
It's a normal feature of the HFS+ file system, which is the default on the Mac
(both OS 9 and OS X). You can also use the UFS file system, which is the
standard Unix one with the case-sensitive behaviour. But 99% of the users are
using HFS+, which is the most user-friendly one.

We used to have a lot of issues with the UFS (couldn't start on UFS f.i., see
bug 86538), but that's fixed now. In general it doesn't cause a lot of problems,
except for makefile/Makefile and some Perl module-imports. The reason why people
aren't using UFS, is that it's a lot slower, and it isn't installed by default
(it's not recommended for the boot disk anyway). And users would scream hell and
murder when they discover a case-sensitive file system. (Steve would be
castrated if he tried to force that :-)

PS : the file system itself is actually case-preserving, but the file-lookup
routines will force case-insensitiveness. That's why the second 'touch' found
the first one (when using stat I suppose), and ls displayed a lowercase filename.

It might be a legacy convention, but it will /never/ go away.
-> default owner
Assignee: darin → nobody
Component: Networking: File → Networking
QA Contact: benc → networking
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.