Disk Image Mountpoint Problem

[simplebeep]

I've always wanted a good way to encrypt some of my files, i.e. without plunging into FileVault completely. It's never seemed right to me to just make an encrypted disk image that mounts on my Desktop, though. Recently, I learned that using the hdiutil terminal command, you can mount a disk image at any folder in the filesystem.

This doesn't seem to be working, however. I have an encrypted sparsebundle (HFS+journaled) at ~/Library/Miscellaneous/Blergmeister.sparsebundle, and an empty folder (which should be the mountpoint) at ~/Documents/Blerg. I have its password stored in my Keychain, so that it can be opened easily once I log in. So, I issue the command:

hdiutil attach /Users/myself/Library/Miscellaneous/Blergmeister.sparsebundle -mountpoint /Users/myself/Documents/Blerg

At this point, ~/Documents/Blerg should populate itself with the contents of the disk image.

What happens instead is the "removable drive" icon appears on the desktop and in my sidebar, while the Blerg folder mountpoint gains an alias icon (see screenshots). Yet when I check on the location of the Blerg "drive" on the Desktop (by, say, dragging it to a Terminal window), the mountpoint is correct! So the filesystem is doing exactly what I'm telling it to do, but the Finder is showing me exactly the wrong thing.

Is there any way to get around this failing? The whole purpose of this system is to have several different "encrypted folders" inside my Home folder whose contents are represented in sparsebundles, and not clotting up my Desktop. Any help is much appreciated.

 

[larkost]

Ya, add the '-private' flag to your mount command, and the Finder will not see the mount event, so will not list it places.

I will warn you that sometimes this screws up the 10.5 Finder (it gets confused about what images are mounted where, and starts to mix them up), but I have not seen that particular problem with 10.6. Of course I only saw this problem after an InstaDMG session or two, so I was regularly juggling 20 or more images, all of them mounting in hidden spaces, and quite a bit of chrooting going on. All in all not a normal situation.

 

[simplebeep]

Many thanks, @larkost.

It turns out that -private did not work, but that got me looking in the manpages. According to the documentation, -private "should be avoided." It only shields the image mounting event. There's an official flag that does exactly what I had hoped: -nobrowse specifically tells Cocoa (and maybe Carbon) to not display the image as a drive in any filesystem listing.
Fantastic!

Thanks again, at least for getting me on the trail. (And it looks like this is a flag you can use to avoid the problems you were having.)
It also reminds me of a great coffee shop in Salt Lake: Nobrow.

 

[larkost]

Sorry about that... I was looking somewhere else when I copy-pasted that in from the man page... you are right, it should be -nobrowse. Sorry.

And no... that does not avoid the problems. Here is the line we use (includeing a few variables):

/usr/bin/hdiutil mount "$TARGET_IMAGE_FILE" -nobrowse -noautofsck -noverify -puppetstrings -owners on -mountpoint "$TARGET_IMAGE_MOUNT" -shadow "$SHADOW_FILE_LOCATION"

So something in that caused the problems, and it all started when I switched to using the -nobrowse option.