The Living Thing / Notebooks :

Eking file storage out of OSX filesystems

See also command lines it is tedious to remember for general unix/osx/BSD commands.

Most of these commands are supposed to be run sudo root, and each may irremediably erase up your data, the data of your friends, the data of your enemies, and you’ll have to go running to the NSA to restore your messages from their backups.

This was split off from general OSX hacks.

Dealing with the transitory, ephemeral nature of data Apple encrypted drives

The best way to make sure nobody reads your confidential data is to make sure you never store it in the first place. Fortunately, Apple has a solution here - FileVault 2! You encrypted something using Filevault 2 on an external drive? Expect the entire disk full of backups to become unusable next time the cable jiggles, and all your data will be, uh… securely deleted for your convenience.

If you like your data keep at least two copies, on two different disks, to compensate for this convenience.

But you need to take one more step; in periodically reformatting whichever drive most recently corrupted itself and and cloning it from the other drive, you might find that you can’t even erase it. Instead you will get an error unable to delete core storage logical volume.

How to delete Apple encrypted drives that Apple fucked up by being fragile:

diskutil cs list
diskutil cs deleteVolume <UUID>
diskutil cs delete UUID-OF-COREVOLUME-GROUP

That doesn’t work? Boot into Linux and nuke it that way.

Or try this cowboy option:

cat /dev/random > /dev/diskBLAH
^C

Rebuild Spotlight index

Is it working?

sudo mdutil -sv /

No? Turn it off and on again

sudo mdutil -E /

Filesystem watcher notifications never triggered

If your filewatching is never triggered :

OS X FSEvents bug may prevent monitoring of certain folders OS X has a rarely-occuring bug that causes some folder to get ‘broken’ with regards to file system change monitoring via FSEvents.[…]

In case you wonder, the bug is related to case (in)sensitivity of the file system. For certain folders, either realpath or FSCopyAliasInfo APIs report their names in incorrect case. This somehow causes the FSEvents system (used by LiveReload to monitor file system changes) to never report any changes for those folders and their subfolders.

(If you are really curious, more details can be found in Radar #10207999, in rb-fsevents issue #10 and in find-fsevents-bug repository.)

Note: this is not a “rarely occurring bug” in the sense that it happens one in a thousand times you change the case of some file name; It happens every time. However, between people not often changing the cases, and people not often using file-system-monitoring explicitly themselves, this is probably a rarely reported bug.

Mounting foreign files systems

What do you have to do to get foreign filesystems to mount using FUSE this week?

Don’t. Read native file systems and share the results over the web or a USB key. But for my failures in this ares, see How is mounting foreign file systems in OSX awful.

Burning bootable ISO images to USB

Via Evan Borgström.

Convert ISO to DMG:

hdiutil convert -format UDRW -o debian-6.0.7-amd64-netinst.img debian-6.0.7-amd64-netinst.iso

Find which disk is which:

diskutil list

Say it was /dev/disk3… Unmount and clobber the right one (careful now) with the new dmg:

diskutil unmountDisk /dev/disk3
dd if=./debian-6.0.7-amd64-netinst.img.dmg of=/dev/rdisk3 bs=1m
diskutil eject /dev/disk3

Doing this without intermediate dmg output left as an exercise for the premature optimizer.

Filesystem updates never triggered

If your filewatcher is never triggered :

OS X FSEvents bug may prevent monitoring of certain folders OS X has a rarely-occurring bug that causes some folder to get ‘broken’ with regards to file system change monitoring via FSEvents.[…]

In case you wonder, the bug is related to case (in)sensitivity of the file system. For certain folders, either realpath or FSCopyAliasInfo APIs report their names in incorrect case. This somehow causes the FSEvents system (used by LiveReload to monitor file system changes) to never report any changes for those folders and their subfolders.

(If you are really curious, more details can be found in Radar #10207999, in rb-fsevents issue #10 and in find-fsevents-bug repository.)

Note: this is not a “rarely occurring bug” in the sense that it sometimes occurs when you capitalise a letter in a filename; AFAICT it is triggered every time. Rather, it is a rarely noticed bug, since I guess either changing capitalisation or running filewatchers, or the intersection thereof, is rarely notices. Regardless, the above diagnoses seem to hold. Delete it and copy it from elsewhere.