Mac OS X 10.5 (Leopard): Ejecting disk images still a hit-or-miss proposition
Posted by Pierre Igot in: MacintoshNovember 8th, 2007 • 4:57 pm
For years Mac OS X has suffered from a certain level of flakiness when it comes to ejecting mounted disk images. In a typical scenario, you would double-click on a .dmg file, which would cause Mac OS X to mount the disk image as a removable disk on the desktop, then you would launch an application located on this disk image—typically an installer application—then you would quit the application, do some other stuff in the Finder or elsewhere, and then you would notice at some point that the disk image was still mounted as a disk on the desktop.
So you would drag the mounted disk to the Trash, or click on the “Eject” button next to the mounted disk in the Sidebar, or you would right-click on the disk image in the Finder and select the “Eject” command in the contextual menu.
And then… nothing. The Finder would refuse to eject the disk, without any explanation. There wouldn’t be an error message complaining that Mac OS X could not eject the volume because it contained something that was still in use. It would just flatly refuse to eject it.
Alternatively, it would eject it, but there would still be a ghost copy of it either in the Sidebar or on the desktop or in the main area of a Finder window.
In other words, the whole thing would be rather flaky.
Since the Finder underwent significant renovations in Leopard, it was my hope that such things would be a thing of the past.
Sadly, I have just experienced the exact same thing with a disk image downloaded off the Internet earlier today. I mounted it, ran an installer, quit the installer, forgot about it, and then later on when I went to eject it, it just refused to do it in the Finder.
I ended up launching Disk Utility and using the “Eject” button in that application. There, for some reason, it worked, and the disk finally disappeared from my system.
It really is frustrating that Apple still cannot get such a basic thing right, especially since disk images are the preferred mode of distribution for Mac OS X software.
So I guess it’s still the same old flaky Finder after all. Sigh.
November 8th, 2007 at Nov 08, 07 | 6:38 pm
Huh? DMG files eject for me just fine (usually). I pretty much always get an “in use” message if such is the case, and if not the image unmountw just fine. I said “usually” because sometimes a DMG will remount itself without asking, but they always obey the second time.
November 8th, 2007 at Nov 08, 07 | 6:40 pm
And yes, that should say “unmounts.” So it goes with an iPhone’s keyboard.
November 8th, 2007 at Nov 08, 07 | 7:02 pm
Well, everyone has a different experience. All I can say is that this is not a rare occurrence for me, and the fact that I was already able to reproduce it within 2 days of installing 10.5 tells me that things are not improved.
November 8th, 2007 at Nov 08, 07 | 8:08 pm
I’ve never seen this either, and it seems like I would — I’m a hot-new-software junkie and download lots of disk images. Once in a while an installer will leave something open, but Finder has always told me that files were in use; I’ve never seen flakiness in the unmount/eject process itself.
(I do object to their ongoing use of the term “eject” for disk images, but I digress.)
November 8th, 2007 at Nov 08, 07 | 11:54 pm
Well, all I can say is that it happens to me, and not just once in a blue moon! I click on the Eject button, and the icon does not go away, or it goes away in the Sidebar and not in the main area of the window, or the other way around. Flaky.
As for the terminology and the enduring drag-to-trash shortcut, well, obviously no one has come up with anything better yet!
November 9th, 2007 at Nov 09, 07 | 6:46 am
I’ve experienced this a few times in Tiger, and also in Leopard. So it’s not just you Pierre!
I usually experience it when I have lots of images mounted at once – like when I’m installing a lot of software on a new machine. What I find unusual is that some of the images would unmount, but others would remain.
November 9th, 2007 at Nov 09, 07 | 6:52 am
I have been lucky with disk images so far. My worst problem with them is that sometimes they won’t mount until the next restart for unknown reasons (also seen in X.5 already).
I only know unmounting problems from files still being open on the volume (usually coming with an unhelpful Finder error message). When you’re having this problem it might be interesting to run something like ‘sudo lsof | grep volume’ where volume is the name of the mounted disk image to see whether that could be the cause.
As for the Finder sidebar. Of course it’s an unreliable POS. But we don’t expect anything else, do we? Yesterday it managed to display two different icons for two external volumes but selecting either of them would show the same volume in the window. Argh!
November 10th, 2007 at Nov 10, 07 | 4:41 pm
Andrew: Thanks for confirming that I’m not alone.
ssp: I am aware of the use of lsof to identify which application still has open files on the volume. But in this case there is no message that OS X can’t eject because some files are still in use. So it’s a different problem.
November 10th, 2007 at Nov 10, 07 | 10:23 pm
I’d suspect that it’s a different problem as well, but the Finder being the piece of wonderful programming that it is could just be bad at delivering the news. So checking for open files might be a first step towards getting an idea about the problem, or at least excluding one cause for it.
Another thing to do might be trying to use the umount command and see whether it works or why it fails.
November 12th, 2007 at Nov 12, 07 | 4:59 am
Not that it’s a better workaround, but have you tried relaunching Finder and checked if you could eject (unmount, deattach) the disk image volume afterwards? I’m curious is because it reminded me of this bug that crept into 10.4:
Duplicate (command-D) in Finder generates error -8058 when attempting to duplicate certain items. Example: mount a disk image, select its desktop icon, and duplicate it. Error. And the volume won’t unmount until Finder is relaunched.
Haven’t checked if that’s fixed in 10.5 since I’m not running it yet.
And the new locked, hidden .HFS+ Private Directory Data^M (yes, with a trailing Control-M) directory in the root of a mounted 10.5 disk image volume can cause trouble if you copy the top-level directory (e.g. by Option-click dragging its Desktop icon somewhere, or Command-D to Duplicate it if that works again). I discovered that new-in-10.5 directory when its locked state was keeping Trash from being emptied. Also noticed the new .fseventsd directory but since its unlocked it’s not causing problems like the other one can.
November 12th, 2007 at Nov 12, 07 | 10:43 am
sjk: I have used the Finder relaunch workaround in the past. I did not in this particular case, but it is indeed part of my arsenal (and I agree that Finder flakiness is probably part of the reason for these disk unmounting problems).
FWIW, I cannot reproduce the Error -8058 problem on my machine. 10.5’s Finder correctly duplicates the mounted disk image by creating a folder with the same name and contents, and things can be unmounted/trashed without difficulty.
November 12th, 2007 at Nov 12, 07 | 3:52 pm
I minimize Finder relaunching whenever possible because of unsaved cache behaviors I’ve noticed and vaguely remember reading about.
Thanks for checking on that Error -8058 Duplicate bug in 10.5’s Finder. Glad to know it’s apparently fixed because before 10.4 the Command-D shortcut had been so convenient for cloning the content of mounted disk image volumes. Still thinking of ways to best handle the locked .HFS+ Private Directory Data^M directories in them. So far I’ve got Hazel monitoring my ~/.Trash folder to unlock them when they show up there.
November 13th, 2007 at Nov 13, 07 | 3:29 pm
sjk: Don’t know if you are aware of this, but with Activity Monitor you can actually quit (and relaunch) the Finder without force-quitting it. Just quitting the Finder with AM saves your current workspace (open Finder windows, etc.), so I tend to suspect that it is a regular quitting process just like the one Mac OS uses when restarting, and that it clears caches as well.
November 13th, 2007 at Nov 13, 07 | 9:28 pm
You can also add a Quit menu to Finder quite easily — “defaults write com.apple.finder QuitMenuItem 1”. (Remove it again, if for some reason you want to, with “defaults delete com.apple.finder QuitMenuItem”.)
Then you can just quit Finder with Command-Q, like any other application; and relaunch from the Dock or QuickSilver/LaunchBar/Spotlight.
Works in Tiger and Leopard, don’t know about pre-Tiger.
November 13th, 2007 at Nov 13, 07 | 9:49 pm
My normal method for relaunching Finder is to option-click its Dock icon and select Relaunch. Maybe that differs from using Quit Process in Activity Monitor (thanks for the suggestion) and/or running “killall Finder” in Terminal (with a default SIGTERM signal) and/or using AppleScript? I really should do some comparisons of all those. On occasions when Force Quit is necessary it usually means other concerns supersede what Finder state will/won’t be saved.
November 13th, 2007 at Nov 13, 07 | 9:57 pm
Dan, your reply snuck in before I’d finished mine. Adding a Quit menu item to Finder is definitely possible in 10.3, and I may have temporarily enabled it further back in 10.2 or even 10.1 using TinkerTool.
November 13th, 2007 at Nov 13, 07 | 11:20 pm
sjk: If you look at the behaviour in the Force Quit dialog box, you’ll see that the button changes from “Force Quit” to “Relaunch” when you select the Finder in the list. So I suspect that “Relaunch” is indeed the same as a Force Quit, and not as a regular Quit. It would also be consistent with the behaviour of other application icons in the Dock. The difference between “Relaunch” and “Force Quit” is simply that, in the case of the Finder, the Force Quit is immediately followed by an automatic relaunch of the application.
The ultimate test is to check the state of you Finder windows before and after a Relaunch. If you change the state of your windows just prior to the Relaunch and then Relaunch and the state is not exactly the same as it was before the Relaunch, then it confirms that a Relaunch does not save the state, and that the Finder has reverted to the last saved state instead.
One can only assume that other normal Finder-quitting procedures (cache clearing, for example) are also followed when quitting it, whereas they are not applied when relaunching.
November 19th, 2007 at Nov 19, 07 | 7:36 pm
With the hint mentioned above to restart the finder and then eject the mounted images does the trick. I have oft images that will not eject.
So it’s option click finder in the dock. Choose relaunch. Then you are able to eject every image.