Feisty Gnome Umount Utility displays empty Info Boxes on Failure

Bug #118467 reported by a-r-k-i-b-o-t-t
20
Affects Status Importance Assigned to Milestone
GNOME Applets
Expired
Low
gnome-applets (Fedora)
Won't Fix
Low
gnome-applets (Ubuntu)
Invalid
Low
Ubuntu Desktop Bugs
gnome-mount (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

When you access (for Example copy some Data to the Device) a mounted Device while you try to unmount it via the little Applet in the Panel, you might get 3 MessageBox Info's:

1st
Cannot unmount volume.
An application is preventing the volume from beeing unmounted.

2nd
A completely empty MessageBox. (only sometimes empty)
Cannot eject volume.
...

3rd
Just a Red sign - Empty. (this MessageBox is always empty!)

If it depends on the Language - the Messages should be displayed in German but the Messages are displayed in English. Only the last window Title (3rd) is correct.

Tags: bitesize
Revision history for this message
a-r-k-i-b-o-t-t (arkibott-ray) wrote :
Revision history for this message
a-r-k-i-b-o-t-t (arkibott-ray) wrote :
Revision history for this message
a-r-k-i-b-o-t-t (arkibott-ray) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug. How do you trigger the bug? What locale do you use? Does it happen every time you try to eject anything?

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
a-r-k-i-b-o-t-t (arkibott-ray) wrote :

Mount some device. Move to a Path on that device inside the Bash and/or use a File with an application. Then try to unmount it.

It is in the Feisty 7.04 Version.

Do you mean localized Language support? Some parts are translated to German. If you need more detailed Information, please tell me, how to find that Information.

Changed in gnome-applets:
status: Incomplete → New
Revision history for this message
David Tomaschik (matir) wrote :

Both in Gutsy and in Hardy Alpha 3, I see this same behavior only with only 2 boxes. I receive 1 box that states that "An applications is preventing..." and then an empty one with the title "Unmount Error".

Changed in gnome-mount:
status: New → Confirmed
Revision history for this message
David Tomaschik (matir) wrote :

Performing an xkill on the last dialog also kills the gnome disk mounter applet. Also, attempting to unmount from within nautilus produces only a single dialog.

Changed in gnome-mount:
status: Confirmed → Invalid
Changed in gnome-applets:
status: New → Confirmed
Revision history for this message
David Tomaschik (matir) wrote :

A little more information: it seems that mount_result in drive-button.c of gnome-applets produces its own error dialog in addition to that produced by gnome-umount in gnome-mount. Is this dialog necessary at all? It seems that char *error is empty anyway.

Revision history for this message
David Tomaschik (matir) wrote :

I've reported this into the Gnome bugtracker: http://bugzilla.gnome.org/show_bug.cgi?id=511139

Hopefully we can get an upstream fix.

Changed in gnome-applets:
status: Unknown → New
Revision history for this message
In , Hans (hans-redhat-bugs) wrote :

Description of problem:

  When trying to unmount a filesystem via the disk mount applet
  while the filesystem is still in use, gnome-mount displays a useful
  error message:

    +---[]-----------------------------+
    | Cannot unmount volume |
    | |
    | An application is preventing the |
    | volume 'foobar' from being |
    | unmounted. |
    | [ OK ] |
    +----------------------------------+

  It comes from gnome-mount and has no window title, but at
  least it shows some kind-of informative text.

  After the user clicks [OK], /usr/libexec/drivemount_applet2
  shows this useless error dialog:

  +-[Unmo]-+
  | |
  | [OK]|
  +--------+

  xwininfo tells that the title should be "Unmount Error".

Version-Release number of selected component (if applicable):

  gnome-applets-2.22.1-1.fc9.i386

How reproducible:

  always

Steps to Reproduce:
1. Insert any hotpluggable device with a filesystem.
2. Wait for hal/gnome-mount to work their magic and mount the FS.
3. Open terminal window and "cd /media/proper-dir" to simulate the app.
4. Click "Unmount foo" in the disk drive mounter applet.

Actual results:

  +-[Unmo]-+
  | |
  | [OK]|
  +--------+

Expected results:

  Either a useful error message or none at all, as gnome-mount has already
  popped up one.

Additional info:

  The useless empty error dialog does NOT pop up when trying to unmount the
  filesystem from the Gnome file manager thingie (is it still called
  nautilus?) or by running "gnome-mount -u -d /dev/sdb1" from a terminal.
  This makes me think the "Disk Mounter" applet is the culprit.

  Oh, and why does the "*Disk* Mounter 2.22.1" (About dialog) correspond to
  the /usr/libexec/*drive*mount_applet2 executable (emphasis mine)? That is
  confusing, to say the least.

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Changed in gnome-applets:
status: Confirmed → Triaged
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 9 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Revision history for this message
David Stansby (dstansby-deactivatedaccount) wrote :

Thank you for reporting this bug to Ubuntu. 7.04 reached EOL on 2009-04-18.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

I've tried recreating this bug with 9.10 and was unable to given the information you've provided. Please either a) upgrade and test or b) increase the verbosity of the steps to recreate it so we can try again.

Please feel free to report any other bugs you may find.

Changed in gnome-applets (Ubuntu):
status: Triaged → Incomplete
Changed in gnome-applets (Fedora):
status: Unknown → Confirmed
Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in gnome-applets (Fedora):
status: Confirmed → Won't Fix
Changed in gnome-applets:
importance: Unknown → Low
Changed in gnome-applets:
status: New → Expired
Changed in gnome-applets (Ubuntu):
status: Incomplete → Invalid
Changed in gnome-applets (Fedora):
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.