Apple has revised the Technical Note 1550 and officially documents for the first time the new features of HFS+ which have been introduced with Panther:Journalling, HFSX (an extension of HFS Plus that allows for case-sensitive file and directory names), Metadata Zone (a new policy which places the volume metadata and frequently used small files (“hot files”) near each other on disk, which reduces the seek time for typical accesses) and the adaptive hot file clustering (as files are moved into the metadata zone, they are also defragmented).
HFS+’s New Features in Panther Now Documented
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Finally!
“A variant of HFS Plus, called HFSX, allows volumes whose names are compared in a case-sensitive fashion. The names are fully decomposed and in canonical order, but no Unicode characters are ignored during the comparison.”
(http://developer.apple.com/technotes/tn/tn1150.html#HFSX)
I wonder if they’re going ahead with HFSX or they’re switching to some other filesystem (hopefully one without fscking forks)
You can find it at;
http://cvs.opendarwin.org/index.cgi/src/xnu/bsd/hfs/
[)amien
@ Damien:
Are you actually *complaining* about documentation?
<rant>
I, for one, much prefer to read plain english with a couple of images, when looking for the whatabouts of a technology, than reading the same amount (or more) in source code.
The source is *not* the documentation, even if a popular hacker proverb says otherwise. Code tells you the *how*, yes, but the *what* is usually pretty obfuscated, and most coders believe no-one is interested in the *why* anyways.
</rant>
Nice to see these performance improvements going in.
Why are we going backwards here? Wasn’t some well known reviewer somewhat recently extoling the virtues of the case-preserving-but-not-sensitive file system behaviors in OSX? I think it might have even been Scot Hacker. After reading what he had to say on it, I thought he articulated it well, I tended to agree with the system. Now Apple’s taking that away and digging deeper into the old Unix geekisms.
Case-sensitive file systems are geek territory and are not user friendly. How do you explain to non-geeks why a file named “my paper” should be considered as being any different from a file named “My Paper” ??
BAD move.
It’s an option during install, and the installer still defaults to case-insensitive. There was a lot of demand for it, so Apple delivered, without compromising on user-friendliness…
From a quick test, it looks like this is not enabled by default…
chris@windu:~/test/case$ touch junk
chris@windu:~/test/case$ touch JUNK
chris@windu:~/test/case$ ls
junk
Darwin windu 7.2.0 Darwin Kernel Version 7.2.0: Thu Dec 11 16:20:23 PST 2003; root:xnu/xnu-517.3.7.obj~1/RELEASE_PPC Power Macintosh powerpc
I believe there is a way to enable it when formatting a partition, but I guess this isn’t a big deal for the masses if it’s not enabled by default.
Case sensitivity is needed for some unix applications. Since OSX is increasingly being used as a unix style workstation, this is important.
First, it is a choice, and second, I personally think that case insensitivity should be implemented at a higher level. No reason that the application layer shouldn’t be able to toggle case sensitivity on the fly, assuming of course the OS X api’s (for OS X programs) are well designed.
Don’t see any problem there. Non-geek generally do not use the terminal, where typing errors could really be a problem. And, unless the system itself names files My PaPer, my pAper, mY papeR (which it doesn’t) he wouldn’t ever see such names. Users use my paper 1, my paper 2, my paper 3…
As a Linux->OS X switcher I thought the case-insensitive thing was going to suck, but it’s actually just fine. You just have to be sure to turn on case-insensitive tab-completion in bash (which I’ve come to like enough to enable on my Linux boxen as well). The only real problem I’ve ever had was somebody committing two files to CVS that had the same name with case differences. When I tried to update the directory CVS got pretty confused. 🙂
In the end, that was a mistake by the person who committed the files.
Any software that *relies* on case differences in the filesystem is broken by design. I have yet to encounter such software, so I’m dubious of the claim that it’s “needed for some unix applications.” Almost all modern unix software is designed to be cross-platform, and OS X is one of the most important unix platforms, so if you were to find such a rare piece of software it would likely be handled as a bug quickly by the software’s authors.
At my college a few years ago I helped a few African exchange students who had never touched a computer before — Their course had a small section on MSDOS, and they were VERY confused by MSDOS’s case-insensitivity.
They had a textbook they were using and they followed the steps _exactly_ as they were in the book. The book showed commands in uppercase (I suppose to differenciate them from the arguments), when I went to help them I used lowercase. This confused them, and trying to explain that case-sensitivity didn’t matter wasn’t easy. Why? because ‘SHIFT+CD’ is most definately different than ‘cd’. Remember these were people who had never touched anything resembling a computer before. One might suggest the book was to blame, and that the author should have used all lowercase, but then I can’t help but think “why even bother? what are you gaining from case insensitivity?”
After a considerable amount of thought on the matter I sometimes think maybe it would be easier to throw away uppercase altogether — its purposes seem questionable at best, and the use of uppercase has always been implimented in the most bizarre manner. Any body ever try ‘properly’ writing a book title? Some words get uppercase, some don’t, and somehow I never get it right.
First things first: I think that case sensitivity is, on the whole, for the better.
However, I’ll avoid defending that position, because ultimately I think the whole point of file names conferring some sort of uniqueness is silly. A user should be able to have as many identically-named files as s/he wants. Some counter-examples, both from “real life” and from the electronic world:
I have, on my bookshelf, three different copies of “Into Thin Air”. The names (titles) are identical, the author is identical, and at least in two cases the contents are identical (the other one is an expanded edition with additional commentary, pictures, annotations, etc.) So I can have x number of books on the same shelf with identical names, yet demonstrably unique in other characteristics. For some reason all of my computers, regardless of OS, feel that having multiple files called “Into Thin Air” in the same folder isn’t possible, even if the contents vary dramatically.
I have, in my email client (and NNTP client, come to think of it) numerous examples of identically named (identical subject) emails/posts in the same folder. Often by the same author. Yet neither my client not I have any problem with this.
I have, at my employer, a co-worker with exactly my same name. We are nothing alike and manage to co-exist without controvery
So why is it that the somewhat archaic principle of a “filesystem” should impose *any* naming restrictions at all? (Or even require a user-visible name.) A name should just be one additional piece of metadata; manipulation of an object should be dependent on other identification methods and unique identifiers (whether those are visible to users or not). I will grant that this makes some interesting problems for GUIs and some frighteningly difficult problems for CLIs, but I believe that starting with the premise that [user-visible] names aren’t unique identifiers could lead to some interesting advances in user interface design and philosophy.
You make a few fine analogies, but wouldn’t three files with the same name really complicate things when using the command line? If we “ls -l” and get
8983 May 28 2004 file.txt
1024 Apr 01 2003 file.txt
4096 Dec 31 1999 file.txt
then what is the behavior of:
rm file.txt
Does this delete them all? Does it prompt again asking which of the three? If the the latter is true, we’ve just moved to having to execute TWO commands when we currently only need ONE.
While I can picture some scenarios where redundant filenames can be useful, I tend to think that they’d cause more confusion than not. To continue your example (if I may
), you can peacefully co-exist with your co-worker of the same name, age, height, weight, (heck you could even be twins). Yet you both must have a single unique identifier in your environment (in this case, your workplace), and that is your Social Security Number (in the US anyway, or equivalent employment number). Make sense? 
Interesting concepts. But you have a visual differenciation of the three books on your bookshelf. It would be easy to have the same thing on a computer, at least with a GUI (icon with different color, different size). It would be more difficult with a CLI.
I love the idea of the name being just another piece of metadata. Anyway, generally, the content of a file is more important than its name, and very often we try to have a name somehow reflecting the content.