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