Strange. This works for me both on phoebe and on 8.0 with gnome 2.2 from cvs.
Can you use lsof to see exactly which file is open on it?

Turns out that the essential step here is to double click on a HTML
file on the CD and launch mozilla. If you then close everything, you
get into the stuck state.

fam is monitoring the directory in which the file that you launched
was in.

I don't understand this at all. I was able to reproduce this once (the first
time), but now it works all the time. (Mine opened in OOo instead of moz though.)

Ok, i finally tracked this one down. The problem is not nautilus itself, the
problem is the recent-files code. It (via the panel) opens a monitor on the
files in the recently-opened list.

This totally sucks, because it means any document opened on a removable media
will be unmountable until you've opened some more documents to push the first
document off the list.

I don't really know why its monitorig the file. Not monitoring read-only mounts
helps a bit, but still means floppies and other removable writable media are hosed.

To top it all of the recent-files code is in libegg, so it's cut-and-pasted all
over i guess.

Yeah, this really sucks.  The recent-files code monitors the files in the list
so if one of them is deleted, it gets removed from the list.  I had a gut
feeling that it was going to cause problems some how...guess I should have
followed it.  Anyway, I'm not really sure what to do here except rip out the
monitoring code.  Suggestions?

In the absence of a smarter monitor system (that FAM replacement will have 
"drop all monitors so we can unmount", right?)
turning off monitoring is probably the only quick fix.

A better fix might be to see what mount point you're on and only add the monitor
if it's on a known 'safe' mount point.  I'm attaching some very simple sample
code to check the mount point of a filename.   Regretfully, it uses libgtop, so
you'll prolly have to find Martin and ask him if he minds you extracting the
necessary code and relicensing it.  Not a quick fix, but better than nothing. 
If it's not safe, you can prolly just ping it every 10 seconds or something to
see if it has changed.

Created attachment 89740 [details]
small bit of sample code

Note that the read-write unmountable media problem occurs with Nautilus
as well... it's only the problem with

If we want to handle read-write unmountable file systems, I think
we should probably go off more accurate stuff than path names. (We
can find out the mount device, file system type, etc.) Nautilus
and gnome-vfs already do various things along these lines.

Of course, losing monitoring for nautilus on various volumes would suck;
for the MRU files stuff it's probably less important.

Short term i think we should just disable the monitoring for recent-files
(especially in the panel which runs all the time).

long term the optimal solution would be a kernel API that didn't require you to
keep files open. Barring that I think a fam-replacement could have a "i want to
unmount $path, drop monitors in it" function. heuristics on where to monitor
seem kind of busted.

Latest gnome-panel, gedit and file-roller packages all have this patched out
now. These were all instances i could find, so I think this is fixed.

There seem to be one in gnome-sound-recorder too

I don't see any recent files code in gnome-sound-recorder anymore, so
it looks like this bug is fixed.