After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 401689 - gnome-mount v0.4 does not eject CD tray without media.
gnome-mount v0.4 does not eject CD tray without media.
Status: RESOLVED WONTFIX
Product: gnome-mount
Classification: Deprecated
Component: programs
unspecified
Other All
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gnome[unmaintained]
: 416459 416873 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-01-28 14:04 UTC by Pavel
Modified: 2012-02-28 12:29 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pavel 2007-01-28 14:04:16 UTC
Please describe the problem:
Then in the CD-drive is no media (CD). gnome-mount --eject command show my a popup message
   Unable to mount media.
   There is probably no media in the drive.



Steps to reproduce:
1. drag out the CD from the drive.
2. a) in nautilus window right click on CD-drive icon 
     and select 'eject' menu item
   b) in shell type 'gnome-mount --eject -d /dev/cdrw' 


Actual results:
A popup message:
title:   Unable to mount media.
   There is probably no media in the drive.


Expected results:


Does this happen every time?
Yes ;-)

Other information:
My system is Gentoo-linux 2006.1 x86.  Kernel 2.6.17.
Nautilus V 2.16.3
Comment 1 David Zeuthen (not reading bugmail) 2007-03-05 00:01:33 UTC
I wonder if this is the desired behavior. I'd accept a patch to put an "Open Tray" button in UI for the dialog saying "There is probably no media in the drive". That would require an OpenTray() method on HAL so you would have to do that patch first.
Comment 2 Teppo Turtiainen 2007-03-11 20:23:05 UTC
*** Bug 416459 has been marked as a duplicate of this bug. ***
Comment 3 Teppo Turtiainen 2007-03-11 20:29:22 UTC
I think this is a serious regression and not desired behaviour. I would definitely expect Eject to open the tray regardless of whether there is a disc in the drive or not.
Comment 4 Pavel 2007-03-13 09:42:06 UTC
I think this debate may be resolved by a little Gconf Key, like "/system/volumes/eject_behaviour"
Comment 5 Frederik Hertzum 2007-03-13 20:38:19 UTC
#4: (On Fedora Core 6 at least) /system/volumes/eject_behaviour doesn't exist per default -- do you have any more comments regarding the contents of this key?
Comment 6 Wouter Bolsterlee (uws) 2007-04-18 18:51:40 UTC
It's not in SVN (yet).
Comment 7 Alexander Boström 2007-10-19 17:06:06 UTC
Confirmed on Fedora 7. I've never noticed this before because I use the button on the drive, but this bug was pointed out to me.

If I right-click on an icon representing my empty DVD drive and select "Eject", I would expect the tray to emerge from the drive. I can't really see any reason for any other behavior and I don't know why I would want to confirm opening the tray.

David, is this what you're saying: The HAL method gnome-eject uses is "Eject this disc from the drive it's in", and there's no method that will open an empty tray. Correct?

If you really want to, you could hide the "Eject" menu item when there's no disc in the drive and show a "Open tray" menu item, instead. Maybe that's over-engineering it, but it could be part of the solution for related bug #445927.
Comment 8 Frederik Hertzum 2007-10-19 21:32:40 UTC
A simple eject -t works for me. I have a shortcut for this command on my panel.
Comment 9 Wouter Bolsterlee (uws) 2007-10-19 22:22:40 UTC
(In reply to comment #8)
> A simple eject -t works for me. I have a shortcut for this command on my panel.

<sarcasm>
Sure, using command line programs is really the future of the modern desktop.
</sarcasm>

Come on, we can do better.
Comment 10 Frederik Hertzum 2007-10-20 12:58:49 UTC
I'm just saying that it is quite simple to do it -- the tools have been around for a long time and regardless if there is a disk in the drive or not, eject -t never fails.

There is no reason to do fancy stuff here like, using HAL or D-bus, to eject a disk tray.
Comment 11 Alexander Boström 2007-10-20 13:17:19 UTC
It's good to know that the hardware and drivers will let you do it, so it's just a matter of making userspace tickle the kernel the right way.
Comment 12 Wouter Bolsterlee (uws) 2007-10-20 13:37:27 UTC
(In reply to comment #10)
> There is no reason to do fancy stuff here like, using HAL or D-bus, to eject a
> disk tray.

All hardware stuff should be done using HAL methods so that permissions and lockdown stuff can be done The Right Way.
Comment 13 lexual 2007-11-18 07:14:13 UTC
I see this bug in both Gutsy Ubuntu, and Fedora.
https://bugzilla.redhat.com/show_bug.cgi?id=365071

This is *very* stupid behaviour.
Comment 14 Cosimo Cecchi 2008-01-12 11:15:22 UTC
*** Bug 416873 has been marked as a duplicate of this bug. ***
Comment 15 lexual 2009-07-04 08:18:48 UTC
Still doesn't work with 2.26 in fedora 11.
Comment 16 Frederik Hertzum 2009-07-04 09:51:37 UTC
(In reply to comment #12)
> (In reply to comment #10)
> > There is no reason to do fancy stuff here like, using HAL or D-bus, to eject a
> > disk tray.
> 
> All hardware stuff should be done using HAL methods so that permissions and
> lockdown stuff can be done The Right Way.
> 

GNOME already has another way of ejecting disk trays, if you setup a keyboard shortcut, it is possible to eject and retract the tray irregardless of it containing a disk or not. I suggest making nautilus call the same function as the shortcut and not worry about it using HAL (since it is no longer nautilus' problem).
Comment 17 André Klapper 2012-02-28 12:29:58 UTC
"gnome-mount" will not see active development anymore according to its developers (as HAL is also dead).
Closing this report as WONTFIX - Please feel free to reopen this bug report in
the future if anyone takes the responsibility for active development again.