Bug 81777 - gnome-sound-recorder monitors read-only mount points, preventing unmounting
gnome-sound-recorder monitors read-only mount points, preventing unmounting
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gnome-media (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Colin Walters
Jay Turner
: Triaged
Depends On:
Blocks: 79579 CambridgeTarget
  Show dependency treegraph
 
Reported: 2003-01-13 16:28 EST by Owen Taylor
Modified: 2015-01-07 19:02 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-07-26 13:18:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
small bit of sample code (892 bytes, text/plain)
2003-01-31 13:12 EST, Jonathan Blandford
no flags Details

  None (edit)
Description Owen Taylor 2003-01-13 16:28:04 EST
How to reproduce:

 - Insert a CD, let magicdev mount it (or mount it manually)
 - Open Nautilus on a subdirectory of the CD-ROM. (Not
   sure if the subdirectory is necessary) 
 - Close the window
 - Select eject from the right click menu of the device
   or any other way, and you'll get

    umount: /mnt/cdrom: device is busy

I added code to nautilus at one point so that directories
on read-only mounted volumes didn't get monitored, but
this apparently is no longer working.
Comment 1 Alexander Larsson 2003-01-17 07:36:00 EST
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?
Comment 2 Owen Taylor 2003-01-17 12:38:48 EST
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.
Comment 3 Alexander Larsson 2003-01-21 07:26:45 EST
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.)
Comment 4 Alexander Larsson 2003-01-31 07:26:19 EST
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.
Comment 5 Alexander Larsson 2003-01-31 07:27:05 EST
To top it all of the recent-files code is in libegg, so it's cut-and-pasted all
over i guess.
Comment 6 James Willcox 2003-01-31 09:49:54 EST
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?
Comment 7 Havoc Pennington 2003-01-31 10:43:10 EST
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.
Comment 8 Jonathan Blandford 2003-01-31 13:09:49 EST
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.
Comment 9 Jonathan Blandford 2003-01-31 13:12:31 EST
Created attachment 89740 [details]
small bit of sample code
Comment 10 Owen Taylor 2003-01-31 15:54:05 EST
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.
Comment 11 Alexander Larsson 2003-02-03 11:17:08 EST
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.
Comment 12 Alexander Larsson 2003-02-05 09:27:44 EST
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.
Comment 13 Alexander Larsson 2003-02-05 11:09:35 EST
There seem to be one in gnome-sound-recorder too
Comment 14 Colin Walters 2004-07-26 13:18:12 EDT
I don't see any recent files code in gnome-sound-recorder anymore, so
it looks like this bug is fixed.

Note You need to log in before you can comment on or make changes to this bug.