Author: Walt Stoneburner

CoffeeScript Bundle for TextMate (FIX for Command Not Found)

Installed HomeBrew to get Node.js, used the node package manager to get CoffeeScript, added a TextMate Bundle for CoffeeScript and got a “coffee: command not found” when doing a Command-B. WTF? Here’s how I fixed it.

I installed CoffeeScript on OS X using HomeBrew.

Got this error while using the CoffeeScript bundle for TextMate with the Command-B to Compile and Display JS.

/tmp/temp_textmate.CZvit9: line 12: coffee: command not found

In a new document, typing the word coffee and pressing Control-R to run it, didn’t work.

However, running coffee from the command line worked.
$ coffee -v
CoffeeScript version 1.1.2

Solution: Add /usr/local/bin to the TextMate path.

Files Gone on Drobo FS with OS X Lion? Get ’em back!

Using DroboFS and OSX Lion only to discover that your Drobo shares have no content!? Yikes! But fret not, you merely have a small corruption problem brought on by the firmware, and in moments you can force a rebuild of that database and all your files will be back safe, happy, and sound with no data loss. Here’s how.

I recently updated my DroboFS to firmware 1.2.0 and dashboard 2.0.3 when I switched to Lion, and while my volume mounted there was no data in it although the Drobo lights showed there was capacity, as did the Drobo Dashboard, and the health reports indicated everything was just fine.

I spoke with Drobo Tech Support that indicated this was a known problem they are actively addressing as high priority; the problem is with Lion and their firmware, and we can expect an updated firmware release.

What’s curious about this is that if one uses the Finder and mounts the Drobo drive with SMB, using smb://Drobo-FS/, the files are there. However afp://Drobo-FS.local/ and cifs://Drobo-FS.local/ mount but reveal nothing.

A detailed description of the problem is at the article entitled: “Missing” Data (AFP) and/or CNID DB Errors. This article then leads to a second one, but is only for the brave.

Using Dropbear (SSH) with Drobo FS to regenerate the AppleDB (CNID DB) has detailed steps for regenerating the apple database.

Walt’s More Verbose Directions

  1. Using the Drobo Dashboard login to your Drobo as Administrator.
  2. Unmount all shares.
  3. Under All Devices / Settings / Admin you’ll want to check the Enable DroboApps setting, which will mount a volume entitled DroboApps on your system.
  4. Download a copy of DropBear from the Drobo Apps page.
  5. Unzip this .zip file, resulting in instructions and a compressed dropbear.tgz file . Move the dropbear.tgz file to the root of the DroboApps directory.
  6. Restart the DroboFS by going to Capacity and Tools in the Dashboard, and selecting the Tools drop down on the right side, and selecting Restart. Or, just power off the unit physically for 20 seconds and then turn it back on.
  7. When Drobo restarts, go to the Dashboard and select All Devices / Settings… / Network. Note the IP address given to the device somewhere.
  8. From OS X’s Terminal enter the command ssh root@theIPaddressAbove
  9. The default password is root, unless you’ve used Dropbear before and followed the instructions within it.
  10. Enter the command ls /mnt/DroboFS/Shares to view a list of shares on the drive.
  11. Tech Support promises the following will not cause any data loss, but anytime you’re doing reconstruction you should always have a backup (if you don’t, question your backup policy), and double check before hitting return. For each share of yours listed above, enter the command: rm -r /mnt/DroboFS/Shares/yourShareNameHere/.AppleDB and press return. Note the period indicating it’s a hidden directory.
  12. Exit Terminal by entering exit.
  13. Using the Drobo Dashboard unmount all your shares, which should be just the DroboApps share at this point; this is under the All Devices / Shares and you just uncheck all the boxes.
  14. Restart the Drobo again (see above if you’ve already forgot how).
  15. And just as important restart any Macs connected to the Drobo.
  16. When the Drobo comes up, start the Dashboard, and test the mounts. They should be working.

1Password Woes with Safari Extension (fix)

Safari 5.1 and 1Password 3.7.x not playing well? Getting a Database error? No such column? Overview key missing? Try this… it worked for me.

I’ve been having a very nasty problem using Safari 5.1 with the latest 1Password software, while other browsers like Chrome and Firefox work just fine. I get a red ‘Problem with database’ message that says “Database error: no such column: overview_key”. It looks something like this:

1Password 3.7.1 build 21089 / Safari 5.1 (7534.48.3) / OS X Lion 10.7

Here’s how I fixed it
Start Safari, go to Safari / Preferences… / Extensions, and remove the 1Password extension if you have it. Close Safari. Re-open Safari. Close Safari using the magical sequence Command-Option-Q. Re-open Safari. Open 1Password and use it’s preferences panel to reinstall the Safari extension. Go back to Safari, and if you’re as lucky as I was, it’ll work.

That’s How We Get Socks?

I didn’t know there was a server that made socks.

This morning I noticed the sock drawer was empty, as my wife handed me a pair of some very low-cut socks.

“I know you don’t like these for work, but they’ll have to do. I need to get your socks back online.”

“Back online?”

“Sorry, I meant I have to do laundry. Guess, you’re rubbing off on me.”

JSON and Undefined Object Properties

Ran into an interesting case where the JavaScript object coming out of JSON wasn’t the same as the JavaScript object encoded going in.

When are JSON.parse() and JSON.stringify() not inverses of each another?

Here’s when.

In JavaScript it’s possible to define an object that has an undefined property:

var o = {
    a: "Hello",
    b: undefined
};

It’s then possible to iterate over all the objects properties and see the values as well.

for (var p in o) {
    alert( p + ": " + o[p] );
}

This will show “a: Hello” and “b: undefined”.

Now, to JSON-ify the object and reconstitute it back.
o = JSON.parse( JSON.stringify(o) );

Doing the for-loop again will reveal the object now only has the “a” property (the value is still “Hello”).

Try it.

While I get it, I’m not sure I like it. Ideally, I’d like anything coming out of JSON to be the same as anything going into it.

Assume this object:

var me = {
    mySiblingsGender: undefined
};

This is one of those cases where several subtleties rear their head on edge cases.

First, a known value for mySiblingsGender might be male or female. A null would indicate there is no gender, perhaps by a horrible vegetable peeler accident. (Oh my!) But an undefined value indicates there is one, we just don’t know what it is.

Removing the property completely instead conveys that there is no sibling (absence) — something totally different than null (not having any) or undefined (unknown).

While it’s splitting hairs, if not kindling for religious coding wars, it’s useful to know that JSON-out may not always be the same as JSON-in.

Apple Magic Mouse Sleeping on Win7

My bluetooth Magic Mouse kept falling asleep. Here’s how to keep it away.

My Apple Magic Mouse was “falling asleep” on me in Windows 7.  Found this post that told how to resolve it.

1. Click on the “Bluetooth Devices” blue icon in the system tray (you’ll probably need to click that little UP arrow first) and choose “Open Settings” from the menu.
2. Under the “Hardware” tab of the resulting dialog, select the “Apple Built-in Bluetooth” device and click the “Properties” button on the lower right.
3. Under the “General” tab in the resulting dialog, click the “Change Settings” button on the lower left (it has a shield icon on it)
4. Under the “Power Management” tab in the resulting dialog untick the “Allow the computer to turn off this device to save power” checkbox.
5. Press OK, OK and OK.

But for me, the Hardware tab was located under “Dell Wireless 573 Bluetooth Module with AMP.”

Firefox got real slow

One day Firefox just came to a crawl when running web pages with JavaScript. Then I found out what was causing it and how to fix it. Here’s how.

I was using the Firefox 3.6.16 web browser and it got really slow.  Unbearably so.

When I went to look at the console, it was filled with all kinds detailed of JavaScript warnings, the kind one might expect out of JSLint.  It was spending so much time checking the JavaScript code that it was barely spending time executing it.

The “culprit” was the Web Developer add-on.

Normally, the Disable / Disable JavaScript / Strict Warnings menu item is checked.  Unchecking it gives some fantastic diagnostic messages when writing code.  Forget to re-check it and regular web usage may come to a crawl.

Aside from the console being a clue, you may also see a caution sign or a red circle with a white ‘x’ in it on the Web Developer toolbar.

For normal speeds when regularly browsing, just disable strict checking.

Thick Menu Separators in ExtJS

Do your menu separators on Ext web applications suddenly appear as thick bars instead of thin lines? Here’s how to fix it.

I ran across a problem in Firefox 3.6.16 where my JavaScript applications produced with ExtJS were producing menu separators that were extra thick.

Even Ext demo pages did this: Menu Separator

Here’s how I solved it.

The problem can be addressed with the Web Developer add on.

Normally its Disable / Disable Minimum Font Size is checked. If it gets unchecked, Ext behaves very badly.

Check it and then reload the page; menu separators will be back to normal.

Unicode and the Copyright Symbol

Here’s how I solved the copyright character being changed to an invalid Unicode character block on source control commits.

I ran into an interesting problem with the copyright symbol recently: ©

The symbol appears in the comments of a number of source code files that I work on. And I was noticing that using Subversion‘s difference tool was complaining that my editor was producing an invalid character. The © symbol was changing to that familiar rectangle that says the character is invalid.

I’m using two editors, Notepad++ and IntelliJ Ultimate. I trust both to do the right thing.

Using Cygwin, I was able to dump the file and see what was going on.
$ od -ctx1 filename

In the original file, the © symbol was rendered using 0xA9 (ascii 169). This byte was in that magical 128-255 block, and under certain conditions, with the right code page and font loaded, it would appear as ©, though in many others it would just appear as an invalid character block.

However, if I removed the offensive byte and replaced it with the copyright character, a dump showed something more UTF-8 looking, a byte pair for the character: 0xC2 0xA9

Subversion’s tool then rendered the character properly, as well the compilers and editors working well.

OS X: Incomplete and partial files

Grey folders inaccessible from Finder? OSStatus error -43? Incomplete or partial folders? Here’s what I think is causing them and quite possibly what you can do about them.

I recently bought a Drobo FS with a lot of storage to keep a lot of my photography and other files backed up, redundant, and available.

Even with a “small” source drive, pumping the data to the Drobo at high speed can take a while. This isn’t the fault of the Drobo, nor the network, it’s that there’s just a lot of stuff to push through the pipe.

About 25 Hours to Go

But I ran into an odd problem, and I haven’t been able to get a good answer as to what’s happening. This is a call to geeks.

The problem is when a copy operation fails.

This could be because one rebooted the Drobo during a long copy operation, one rebooted the machine during a long copy operation, or, more likely, OS X Finder just aborted for no good reason and rather than allowing one to try the operation again, resume, or skip the problem area, the whole batch stops.

TIP: It can sometimes be better to have multiple (concurrent but blocked) copy requests that were individually initiated, than one mega-copy operation. Finder seems to like smaller sized chunks, plus if something goes wrong, there’s less to deal with.

What you end up with is a situation that’s hard to describe without seeing it. It’s a destination directory that look like this:

Incomplete Files and Folders
  1. The folders appear as grey.
  2. The folders can not be selected or opened from Finder.
  3. The folders do not have the little triangle icon by them.
  4. The folders can not be renamed from Finder, but can from Terminal.
  5. The folders can be copied, but they copy as grey.
  6. The contents of the folders can be seen using Terminal.
  7. If you use Finder to copy over them, it sees the name in use and makes a similarly named folder with a number after it.
  8. The source files are not in use.

The question is, then, how to ungrey the folders and finish the copy?

So far, I haven’t found a way.

At the moment, I’m speculating if this is related to kFirstMagicBusyFiletype, kLastMagicBusyFiletype, or kMagicBusyCreationDate as shown in the Finder.h header.

Remember, if I have to delete the directory (which can take a while — if it can be done), and then re-copy everything again (which will take a long while), and still not be certain that copy will complete, it’s a huge investment that may not pay off.

Geeks, I know what you’re thinking — I thought it too:

Was the source drive clean?
Yes. I do a Disk Utility check on my source volumes before copying from them.
Was the destination drive clean?
Yes. I do a Disk Utility check on my destination volumes before copying to them. In the case of the Drobo, I had just formatted it, using the latest firmware, and its dashboard gave the all clear. I even peeked with their sshd application.
Did you check the file permissions?
They’re clean with the regular 700 permissions. Finder’s Info concurs.
# ls -ableO@dFGinpqT *
863913 drwx------ 3 501 501 - 264 Feb 13 19:09:02 2011 NormalDirectory/
863912 drwx------ 3 501 501 - 264 Feb 13 19:09:13 2011 WhyIsThisGrey/
What happens if you delete them with # rf -vrf badDir?
Sometimes that works, actually. Other times the delete command just hangs indefinitely, like the file is busy.That said, using the Path Finder shell, this is what you get if you attempt to delete a directory that’s acting up.

OSStatus Error -43

Any idea what an OSStatus error -43 is? Or why they’d be an invalid path inside the destination directory?

What about extended attributes? Type? Creator?
They’re clean, too. Verfied by Path Finder, stat, xattr, and /usr/bin/GetFileInfo.
# stat -x *
File: "NormalDirectory"
Size: 264 FileType: Directory
Mode: (0700/drwx------) Uid: ( 501/ wls) Gid: ( 501/ wls)
Device: 45,12 Inode: 863913 Links: 3
Access: Sun Feb 13 19:09:02 2011
Modify: Sun Feb 13 19:09:02 2011
Change: Sun Feb 13 19:09:02 2011
File: "WhyIsThisGrey"
Size: 264 FileType: Directory
Mode: (0700/drwx------) Uid: ( 501/ wls) Gid: ( 501/ wls)
Device: 45,12 Inode: 863912 Links: 3
Access: Sun Feb 13 19:09:13 2011
Modify: Sun Feb 13 19:09:13 2011
Change: Sun Feb 13 19:09:13 2011
# xattr -l -v -x NormalDirectory WhyIsThisGrey
(nothing returned)
# /usr/bin/GetFileInfo -a -tcdm *
# /usr/bin/GetFileInfo -a NormalDirectory
avbstclinmedz
# /usr/bin/GetFileInfo -a WhyIsThisGrey
avbstclinmedz

No Extended Attributes, according to Path Finder
What happens if you rsync?
Doing an rsync appears to work, but doing it to the “broken directory” does not fix it after it completes.
# rsync --progress -aPE source destination

Further Thoughts

I found an article that suggests there’s a lot more going on with the file system than most of us give credit for. It talks a lot about the importance of meta data.

More Metadata That I First Thought

Two blog posts, The State of Backup and Cloning Tools under Mac OS X and Extended Attributes led me to playing with the xattr and mdls commands.

xattr didn’t have much interesting.

$ xattr -l SomeGreyDir
com.apple.FinderInfo:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020

The mdls command presented a better clue. Check out the kMDItemFSCreationDate attribute.

$ mdls SomeGreyDir
kMDItemFSContentChangeDate = 2011-02-20 14:02:19 -0500
kMDItemFSCreationDate = 1946-02-14 03:34:56 -0500
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "SomeGreyDir"
kMDItemFSNodeCount = 0
kMDItemFSOwnerGroupID = 501
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 0
kMDItemFSTypeCode = ""

A quick romp through my incomplete folders revealed they all had a magical creation date of 1946-02-14 03:34:56 -0500.

The solution I think I need

I’m looking for a way to locate files with the kMDItemFSCreationDate
attribute set to that magic value, and then change it to whatever is in the
kMDItemFSContentChangeDate.

My suspicion is that this will let Finder, and the Apple command line utilities,
consider the file isn’t busy anymore.