Things are, for the most part, working well now. Finally. We’re running Tiger and we’ve managed to iron out the bulk of the problems. There is one issue which has persisted, however: the home account RAID.

To refresh, our network RAID, which is responsible for housing all our users’ home account data, is made by a company called Panasas. Near as I can figure, we’ve got some experimental model, ’cause boy does it crash a lot. Which is not what you want in a home account server, by any means. After upgrading the Panasas OS awhile back, the crashing had stopped. But it was only temporary. Lately the crashing is back with a vengeance. Like every couple of days it goes down. And when it goes down, it goes down hard. Like physical-reset hard. Like pull-the-director-blace-and-wait hard. Like sit-and-wait-for-the-RAID-to-rebuild hard.

Again: Not what you want in a home account server.

So we’ve built a new one. Actually, we’ve swapped our backup and home account servers. See, awhile back we decided it would be prudent to have a backup of the home account server. Just something quick ‘n’ dirty. Just in case. This was built on a reasonably fast custom box with a RAID controller and a bunch of drives. It’s a cheap solution, but it does what we need it to, and it does it well. And now we’re using it as the new home account server. So far it’s been completely stable. No crashes in a week-and-a-half. Keep in mind, this is a $3000 dollar machine, not a $10,000 network RAID. It’s not that fast, but it’s fast enough. And it’s stable. By god it’s stable.

And that’s what you want in a home account server.

Moving to the new server — which, by the way, is a simple Linux box running Fedora Core 4 — has afforded us the opportunity to change — or, actually, revert — the way login happens on the Macs. In the latter half of las semester, we were using a login hook that called mount_nfs because of problems with how Mac OS X 10.4.2 handled our Panasas setup, which creates a separate volume (read: filesystem) for each user account. Since we’re now just using a standard Linux box to share our home accounts, which are now just folders, we have the luxury of reverting to the original method of mounting user accounts that we used last year under Mac OS X 10.3. That is, the home account server is mounted at boot time in the appropriate directory using automount, rather than with mount_nfs at login. Switching back was pretty simple: Disable the login hook (by deleting root’s com.apple.loginwindow.plist file), place a Startup Item that calls the new server in /Library/StartupItems, reboot and you’re done, right? Well, not quite. There’s one last thing you need to do before you can proceed. Seems that, even after doing all of the above, the login hook was still running. I could delete the scripts it called, but it would still run. Know why? This will blow your mind. Cache.

Yup. It turns out — and who would have ever suspected this, as it’s so incredibly stupid — login hooks get cached somewhere in /Library/Caches and will continue to run until these caches are deleted. I’m sorry, but I just have to take a minute and say, that is fucked up. Why would such a thing need to be cached? I mean maybe there’s a minimal speed boost from doing this. The problem is that now you have a system level behavior that’s in cache, and these caches are fairly persistent. They don’t seem to reset. And they don’t seem to update. This is like if your browser only used cached pages to show you websites, and never compared the cache to files on the server. You’d never be able to see anything but stale data without going and clearing the browser cache. At least in a browser — ’cause let’s face it, this does happen from time to time (but not very often) — there is always some mechanism for clearing caches — a button, a menu item, a preference. In Mac OS X there is no such beast. In fact, the only way to delete caches in Mac OSX is to go to one or all of the various Cache folders and delete them by hand. Which is what I did, and which is what finally stopped the login scripts from running.

If this isn’t clear evidence that Mac OS X needs some much better cache management, I don’t know what is.

In any case, we’re now not only happily running Tiger in the lab, but we’ve effectively switched over to a new home account server as well. So far, so good. Knock wood and all that. Between the home account problems, the Tiger migration, and getting ready for our server migration, this has been one of the busiest semesters ever. Though I keep this site anonymous because I write about work, I just want to give a nod to all the people who’ve helped me with all of the above. I certainly have not been doing all of this alone (thank god) and they’ve been doing kick-ass work. And, though I can’t mention them by name, I really appreciate them for it. At the dawn of a new semester, we’ve finally worked out all of our long-standing problems and can get down to more forward-looking projects.

So ends (I hope) the Tiger Lab Migration.

But what’s really gotten my goat is that fact that some of my favorite apps have been left off these lists entirely, often in favor of inferior software. For instance, they often mention Quicksilver, when Butler is, in my humble opinion, a superior product in many ways. And Transmit seems to make nearly every list, despite the fact that there is a superior product known as Yummy FTP. I’m not knocking those products. They are very good. But it’s about time someone mentioned some alternatives, particularly ones that might be better for some folks. I’d hate to see them die for lack of exposure. I’m not going to start my own list. (‘Cause I think they’re dumb, remember?) But I do want to give a shout out to the under-represented. Today I’ll be comparing Transmit and Yummy FTP. Soon I’ll do a face-off between Butler and Quicksilver. If you haven’t checked out these apps, do yourself a favor and forego the conventional wisdom. You’ll be happy you did.

I’ve been a Transmit user for years now. And I’ve been none too shy about singing its praises. But lately it’s had its problems. Don’t get me wrong; I like Transmit. It’s a great product and a very competent file transfer utility. I even paid for the upgrade from version 2 to version 3. Boy was I jazzed when I saw all those new features: column view, in particular, struck my fancy. Finally I could move a file up one directory without doing a “move” operation. I also liked the way Transmit matched the functionality of the FInder. So I bought it.

But after some use, I found some problems with Transmit. My main difficulty is that Transmit has problems with symbolic links. Particularly in column mode. Sometimes it follows links just fine. Other times I get this error:

Transmit Error: Dude, It’s Right There
(click for larger view)

Or it just doesn’t follow the link at all. When this happens, symlinks just stop working, and the only fix is to log out of the server and log back in. Refresh doesn’t do it. Also, following symlinks, when it does work, takes me inside the linked folder but obliterates the file path—I can no longer see the folder that contains the symlink once I’ve navigated into it.

Transmit Behavior: Help! I’ve Followed a Symlink and I Can’t Go Up!
(click for larger view)

There were also weird inconsistencies with file downloads, which I honestly can’t remember as it’s been some time since I’ve used the program. I have to admit, these problems have gotten better in the latest iterations of the software. Transmit was, and continues to be, a wonderful application, but it really has some serious, long standing problems with symlinks in column mode.

Now there is a contender.

Yummy: Follows Links; Less Filling
(click for larger view)

Yummy is the same kind of program, and despite my long-term relationship with Transmit, I’ve switched to Yummy. For some reason, Yummy hasn’t gotten much hype, but if you read the reviews on VersionTracker, people who use this program absolutely love it. Many are former Transmit users. Many switch for the features it offers. I switched simply because I found that Yummy was quite capable of handling symlinks properly and had all the other goodness found in Transmit. I have found Yummy to be extremely stable, and, though I don’t use this sort of program a whole lot, I’ve never had a single problem with it. And one last thing: apparently Yummy’s customer support is fantastic. I’ve only read about it as I’ve never needed any help with this trouble-free app.

If you’re happy with Transmit, that great. Bully for you. But if you’re in the market for a new file transfer application—or if you’ve become dissatisfied with your current one—Yummy is a great choice, and one that folks, unfortunately, don’t mention nearly enough.

So read on, and enjoy!

And a couple other general blog notes:
I’ll most likely not be posting over the holiday, or at least not much. Also, in the pipe is a comparison of two great application-launcher-type utilities — Quicksilver and Butler — inspired by the debate raging (okay, politely taking place) at this TUAW post. If you’re a fan of either of these, curious about them, or love one and are curious about the other (which is the position I’m in), you’ll want to keep your eyes peeled for the face-off. Wow, that sounded weird. You’ll want to watch for the article.

Okay, kids. Happy holidays.

Mmmm… Tongue…

From /var/log/system.log:

Dec 14 16:05:45 ComputerOne crashdump[450]: loginwindow crashedDec 14 16:05:45 ComputerOne crashdump[450]: crash report written to: /Library/Logs/CrashReporter/loginwindow.crash.logDec 14 16:05:46 ComputerOne launchd: /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow port /dev/console exited abnormally: Trace/BPT trapDec 14 16:05:46 ComputerOne launchd: getty repeating too quickly on port /dev/console, sleeping

Reading this led me to check the crash log of loginwindow.app, which showed the below.

From /Library/Logs/CrashReporter/loginwindow.crash.log:

Library not loaded: /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServicesReferenced from: /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindowReason: no suitable image found. Did find:/System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices: unknown file type, first eight bytes: 0x64 0x73 0x74 0x37 0x00 0x00 0x00 0x01

“Hmmm…” methoughts, “Sounds like there’s a corrupt file in the DisplayServices.framework.”

Indeed.

So, using the magic of scp, I copied the DisplayServices.framework from another, working machine, and voilà! The machine was able to proceed to the login window without delay. It’s working fine now.

Theories? Anyone?

So, if you have aliases to several files, say, in a Burn Folder, and you click ‘Show Original,’ the Finder will highlight all the original files. If the original files are in the same folder, they will all be highlighted in one window. If they reside in different folders, each of these folders will open in a new window with the original items highlighted. This saves a lot of time and brainpower if you want to label — or perform any action — on multiple files in your Burn Folder, or any other folder full of aliases.

Maybe this was obvious to most people, but it was certainly a pleasant surprise to me.

is different from typing:
cd /library

To UNIX, /Library and /library are different directories.

However, I’ve found that in Mac OS X, typing either of those commands will put me in the same directory. Mac’s brand of UNIX seems to be case-insensitive. Weird.

Actually, this has to do with the filesystem, rather than UNIX. Mac’s default filesystem is HFS+(Journaled), which is not a case-sensitive filesystem. So the Mac command-line behavior honors this since, on the filesystem, which is at a lower level than the command line, there is no difference between /Library and /library. The command-line environment will, however, mimic case-sensitivity on HFS+ filesystems to a certain degree. For instance, tab-completion of file paths is case sensitive. But typing full file paths seems to default to the case sensitivity of the active filesystem. In fact, if I ssh to a UNIX box or an NFS mount on a UFS or ext3, or other case-sensitive volume, things work as expected in the *NIX world.