Flutterby™! : losing head 2007-01-19 23:58:13.923157+00

losing head

2007-01-19 23:58:13.923157+00 by Dan Lyke 4 comments

John over at Genehack did exactly the same thing to his Mac that I did. In my most recent OS X installation I was smart and copied /usr/bin/head before installing basic Perl modules. Yeah, case insensitive filesystems are braindead, case insensitive filesystems which pretend to be Un*x like are even worse.

Just wait 'til you discover that umount appears to work like you'd expect it would, except that it doesn't. No, on the Mac, it's diskutil unmount /dev/..., except that umount will just silently do nothing while telling you that it did everything, thereby making it far easier to corrupt external media.

There's so much that Apple could have done right with this platform, alas it's amazing at how much ductape and bailing wire appears to be holding it together once you look behind the curtain.

You can make a case-sensitive filesystem. It's just that many apps (especially older Carbon apps) won't run on it.

I guess I feel mildly better that I'm not the only person to have been bitten by this. I was able to pull a 'head' binary over from my work Mac, which means that one file is now a "fat" binary on an otherwise PPC-only machine -- I'm sure that will lead to some mysterious breakage at some point...

Unlikely it'll lead to problems. The intel side won't be run on a PPC. You can strip out the intel side if you want with:

and then replace the fat-head (sorry) with head.ppc. I like fat files - one stop shopping. Different architectures, or 32 and 64 bit versions of a program or library.

I was going to mention the case-sensitive HFS file system, but DaveP beat me to it. You can also make a UFS disk image that lets you do the case-sensitive abortion that is Makefile, MAKEFILE, and makefile (I can never figure out which one is which). Typically what I suggest to alpha nerds is a reasonably sized boot partition that will hold the default /Applications, and any native mac apps you might want to use, and then have a partition or disk image for UFS for Perl stuff (Perl seems to be the main offender with having lots of stuff named the same differing only by case. I guess there's more than one way to name it.)

On OS X, places like /usr/bin/ and /System are the manufacturer's territory. For better or worse, Apple can and will do all sorts of "wrong" things in there. That's why God made /usr/local/bin and/or /opt, depending on your pursuasion. I always put things to /usr/local/whatever, and have never had problems. It also makes migrating all my locally installed stuff from machine to machine that much easier - I have a DocBook (SGML) toolchain, the very definition of pain and suffering, that has survived intact through 5 different machines, three major OS revisions, and one chip architecture change.

One thing to realize is you/we are 99th percentile - the uber unix geek, which is not the Mac's target audience. For the ordinary user, "sales forecast 1999", "Sales Forecast 1999", and "SALES FORECAST 1999" are the same thing. Hell, I've had "professional web designers" stare at me blankely when I say "Blah.JPG gives me a 404 on the server, use Blah.jpg in your html." "but they're the same!"

Given the frankenstein nature of OSX (the unholy union of Mach, *BSD, and Classic Mac stuff), I'm surprised more stuff isn't broken. The Fruit isn't perfect, but I still like it more than any of the alternatives.

For folks having specific problems, like the unmount thing - have you filed bugs via http:// bugreporter.apple.com? (requires a developer account, but it's free, and you can use bogus credentials if you want). It could well be that particular behavior is a real bug. (Then again it might be broken as designed) With the next major OS still in gestation, now's the time to get stuff on the radar.