Version SNAFU

Today I updated WordPress for an “urgent security release,” and as usual there are unexpected side effects. For some reason now, my sliding sidebar panels no longer work. No JavaScript errors; they just don’t do anything. I blame a Scriptaculous update that is probably embedded within. I hope within the next 24 hours to diagnose and fix the problem, but for anyone (emphasis on “one”) who’s wondering why the panels aren’t working, here’s a semi-explanation.

Update (1/1/2008): File under SEU. I think the problem was simply that I needed to clear my cache. The first suspicion was aroused when I fired up MAMP, ran the site locally, and found that the sliders were working just fine. At any rate, I re-uploaded all of my theme files plus the Scriptaculous and prototype.js files, cleared my cache, and now it’s working.

Site girth expansion

I’ve just finished a modification to the site design. I was starting to feel a bit too confined by the narrowness of the old layout, so I’ve basically kept things intact design-wise, but I’ve expanded the layout to be more suitable to today’s 1024×768-or-greater standard screen resolution. I’ve also bumped up the size of the type slightly.

The only design element that’s noticeably different is the little greenish weirdness at the right end of the photos in the header bar. This was something I spent a great deal of time developing for an old, shortlived design that was part of my quickly-abandoned experiment with running the site on Drupal. I may end up getting rid of it again; I just thought it deserved a second chance.

Now then, if you’ve actually visited this site sometime before, you may find the pages are looking somewhat garbled; sadly that’s the side effect of keeping a lot of the filenames the same; your browser likely has old versions of these files cached. Hit the Refresh button a few times or perhaps clear your cache. I did the Refresh thing, but I had to hit it about 4 times before all of the files actually updated. Sheesh, you’d think I was using a Microsoft product or something, not Firefox!

Salvage (part of) a corrupted zip archive in Mac OS X

Perhaps this has been pointed out elsewhere; I haven’t really searched for it, so I don’t know. But it’s rare that I stumble, completely on my own, onto what I believe is truly a “hot tip” for dealing with computer problems, and when I do, I’m excited to share it.

Now then, the problem we’re dealing with here is corrupted zip archives, which seems to be common for me these days given the fact that I’ve foolishly been using some cheap off-brand CD-R’s that have been sitting around my house on a spindle for a couple of years.

The situation manifests as such: You double-click a zip archive to extract the files, BOMArchiveHelper fires up (don’t worry if you have no idea what this is — basically it’s just a background application embedded in Mac OS X for working with zip files), and the extraction process begins.

But then, oh dear. After a while (usually right near the end), the progress bar will change to a disconcerting alert: Unable to unarchive... (Error 1 - Operation not permitted.) Aside from the meaninglessness of the error message itself, you realize, dishearteningly, that the only thing you can do is click the “OK” button, at which point… *poof* everything is gone. Well, the zip file itself is still there, but what good is it if the goodies are forever locked inside?

I’ve discovered, however, that while BOMArchiveHelper is busily extracting the archive, it creates a hidden temporary directory on the hard drive in the same directory as the zip file. Once you click “OK” on this alert, it deletes this temporary directory, but until then, it’s there. With all of the files so far extracted waiting inside. Oblivious to the doom that shortly awaits them.

So what do you do? Well, the first thing you do is get your pointer away from that “OK” button! Leave the alert on the screen, and fire up Terminal. You’re going to need to get your hands dirty with some command line mucky-muck, so if you don’t know where Terminal is, I advise you to just stop right here. Cup your hands over your face and sob quietly.

Now then, this is most likely going to require root access, so type sudo -s and enter your administrator password. Then navigate to the directory where the zip file is. Type ls -al and amongst the hidden files at the top of the list (the ones whose filenames begin with a period), you’ll see a subdirectory named .BAH1234. (The 1234 will be some random number, which I am guessing is the process ID. But it’ll always start with .BAH.) Make note of the exact name, because you’ll need it in a minute.

Everything that’s been extracted so far is inside this directory! So now you can move or copy the contents to another directory and BOMArchiveHelper won’t take it upon itself to “tidy up” after you click the OK button. Here’s some code to try:

mkdir Rescued
mv .BAH1234/* Rescued/

Be sure to change the 1234 portion to whatever the correct name is, as you determined by running ls -al earlier. Also, note that if you’re extracting multiple zip archives at the same time, they may be handled by the same process, so you’ll have a second directory named .BAH1234 2 or something similar. Since this name contains a space, when you’re referring to it at the command line you need to wrap it in quotes, like this:

mv “.BAH1234 2″/* Rescued/

This will create a new (visible) directory at the same place on the hard drive, called Rescued, and it will copy everything from BOMArchiveHelper’s invisible temporary directory into Rescued, where you can now work with the files as you wish. It’s unlikely that everything from the zip file will be in here, but everything that’s not corrupted in the archive will be, and it might just be the things you were looking for.

Once everything’s been moved into your Rescued directory, you can go ahead and succumb to the temptation of that gently pulsating, deliciously blue (or not-so-deliciously gray, depending on your system settings) “OK” button.