So it’s option click finder in the dock. Choose relaunch. Then you are able to eject every image.

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.

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.

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.

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.

I ended up launching Disk Utility and using the “Eject” button in that application.

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.

Another thing to do might be trying to use the umount command and see whether it works or why it fails.

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.

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!

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.

As for the terminology and the enduring drag-to-trash shortcut, well, obviously no one has come up with anything better yet!

(I do object to their ongoing use of the term “eject” for disk images, but I digress.)