Bug 145844 - Better feedback when CD-ROM eject fails
Better feedback when CD-ROM eject fails
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: util-linux-ng (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-22 00:31 EST by Christopher Beland
Modified: 2008-01-28 07:17 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-28 07:17:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christopher Beland 2005-01-22 00:31:42 EST
eject-2.0.13-10
nautilus-2.8.1-4


If, for example, an xterm is visiting a directory on a mounted CD-ROM,
the "eject" command will give the following error message:

umount: /media/cdrecorder: device is busy
umount: /media/cdrecorder: device is busy
/usr/bin/eject: unmount of `/media/cdrecorder' failed

If you try to eject the CD by right-clicking on its desktop icon (this
is in nautilus in Gnome), the operation fails, but there is *no* error
message.

1.) Nautilus should either relay error messages from "eject" to the
    user (perhaps through a popup error dialog box) or originate an
    error message itself.

2.) It would be considerably more useful if eject could report the
    name of the user, process, and/or file that is keeping the CD-ROM
    mounted.  It's not always obvious that you might need to, for
    example, "cd" to an off-disk directory in some xterm, or kill or
    restart some background process.

3.) It would be most smurfy of all if an error message appeared when
    someone presses the eject button on the drive itself, and it is
    not ejected because the filesystem is mounted.  (Right now, I
    don't think it even attempts an unmount when I do this.)
Comment 1 Matthew Miller 2006-07-10 17:05:40 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 2 Christopher Beland 2007-08-26 17:59:14 EDT
Items 1 and 3 have been implemented in Fedora 7!  Yay!

Item 2 has not been implemented; the error message is still generic, which is
better than nothing but still not all that helpful for people who don't know how
to go about figuring out which "application" is using the drive.
Comment 3 Christopher Beland 2007-08-26 18:01:36 EDT
(unsetting NEEDINFO)
Comment 4 Christopher Beland 2007-10-04 18:29:55 EDT
(really unsetting NEEDINFO)
Comment 5 Zdenek Prikryl 2008-01-24 04:17:06 EST
Hello,
eject itself calls a program "unmout". So, it can not give any other information
about processes or files, than umount gives. But I didn't find any option for
umount, which would give this information. So, I'll contact guy who take care of
 util-linux-ng and ask him what is his opinion.
Maybe some additional message would be sufficient. I mean something like this
"Use lsof | grep /cdrom to find a process which blocks umount.".
Comment 6 Zdenek Prikryl 2008-01-24 05:24:04 EST
After little talk with guy from util-linux-ng, we decided to add more talk to
umount command.

So I'm reassigning this to util-linux-ng package.
Comment 7 Karel Zak 2008-01-28 07:17:07 EST
Fixed in the util-linux-ng upstream tree. The message is more talkative now.
You'll see this improvement in Fedora 9. Thanks.

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