One of my least-favorite error messages is the one that says a volume can't be ejected because it is in use. The vague advice to "try quitting applications" often leads me on a wild goose chase -- somehow it always seems to be the last application I try that has a document on the volume open.

I finally realized that the Unix lsof command is exactly what one needs in this situation. I have known about lsof for a long time, but somehow never put two and two together. Now when the Finder tells me I can't eject the volume 'DODO,' I just run this in the Terminal:

This shows me that Word has test.txt open, and that there is a shell whose working directory is on DODO. This makes clear exactly what I need to do to be able to eject the volume -- close the Word document and cd out of the directory on DODO.

[robg adds: This use of lsof is mentioned in the commends to a much older hint I wrote on ejecting a busy disk image using fstat. At some point in OS X's history, it seems fstat vanished (at least as an end-user program) -- I can't find it on either my 10.4 or 10.5 partition, except as a BSD system call in OS X 10.5 -- leaving the use of lsof as the preferred way of finding out what's keeping a disk image busy. Due to that change, I felt it worth running this hint as a standalone refresh of the original. If you have another method, please post it in the comments.]

[Note: This is a near-duplicate of this older hint -- thanks to hayne for pointing this out to me. However, given there's a good chain of comments here, I'm going to leave this hint up. Sorry for the duplication.]

lsof may process this option slowly and require a large amount of dynamic memory to do it. This is because it must descend the entire directory tree, rooted at D, calling stat(2) for each file and directory, building a list of all the files it finds, and searching that list for a match with every open file. When directory D is large, these steps can take a long time, so use this option prudently.

One problem I find often is that it is file sharing that keeps me from ejecting a disk. With no applications running (including background apps), and noone connected to the disk over the network, I can't eject a disk. Only turning off file sharing lets me eject the disk.

I forgot about lsof, and will try it next time to see what exactly is keeping me from ejecting.

That could certainly be. I had this problem a while ago with an external disk shared via SMB and AFP. Both protocols tended to block ejecting the disk. The worst was with windows clients on the network, because there is no obvious way of telling windows to close an open connection.
Also you should note the comment above, about using sudo lsof, because it could be, that file sharing uses a different user account to access the files (i.e. guest account), depending on your configuration.

I wish OS X had this built in. Like a little "details" link in the "can't eject disk" dialog, that lists "file ZZZ is open by process YYY" - and even give a nice app name for processes that belong to a regular application.

After reading through the comments, I've come upon this as the fastest way to find the files:

lsof +fg +D /Volumes/DODO | grep -v EVO

And if that doesn't list anything, prefix a "sudo " to list from all users. Brilliant tip!

The way I understand it, Sloth (http://www.sveinbjorn.org/sloth) gives you a GUI for this.
(This would be helpful if the filtering in Sloth would actually work, currently I have to look through the list of open files for the one I want to eject/delete.

Activity Monitor, has a big "i" next to the "stop sign" that shows you the open files of an app.

Not to be completely dismissive, but that really solves the reverse problem: if I can't throw out a file, I want to know which application has that particular file open, not which files a particular application has open. Also, Activity Monitor's open-file interface (in 10.4, anyway) is inelegant: I just tried looking at the files held open by a few applications, for example, and they all seem to have dozens or hundreds of open files, with no way to search through them or even sort them alphabetically.

QuickTime Player and Preview both (under Tiger at least) regularly cause this problem for me. Besides stopping ejecting disk images, they also prevent ejecting CDs, DVDs or emptying the trash (if you have 'closed' the file and moved it to the trash). Basically these programs fail to properly close files.

This is a 'known' bug by Apple, I have not yet tried upgrading to QuickTime 7.5 to see if it fixes this.