Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 81777
Summary: | gnome-sound-recorder monitors read-only mount points, preventing unmounting | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Owen Taylor <otaylor> | ||||
Component: | gnome-media | Assignee: | Colin Walters <walters> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Jay Turner <jturner> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 9 | CC: | alexl, hp, jrb, mitr, srevivo | ||||
Target Milestone: | --- | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-07-26 17:18:12 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 79579, 100644 | ||||||
Attachments: |
|
Description
Owen Taylor
2003-01-13 21:28:04 UTC
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. |