Consistent Volume "Safe to remove" notifications

Bug #386057 reported by Vish on 2009-06-11
This bug affects 15 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
notify-osd (Ubuntu)
Mirco Müller

Bug Description

At present when a hard drive partition/USB pendrive/external drive is unmounted , safe removal notification is displayed inconsistently. Before the safe removal notification there is a notification that the "writing data to drive is still going on and to wait". But sometimes this wait notification is skipped since the small write operation was over very quickly. So this leads to the user being presented with ONLY the safe removal notification , thus the user is not notified about delay due to the write operation.

But when there is no pending write operation, to delay the unmount, the user is not presented with any notification about safe-removal.

This causes confusion in the regular non-technical user/new users to Ubuntu , who usually keep waiting for the safe removal notifications to remove the drive or leads them to double-check the mount status of the drive before removing the drive

This confusion can be avoided by presenting the "Safe to remove" notification AT EVERY unmount. And this could be done elegantly using the notify-osd notifications for every volume unmount regardless of the delays. The "Wait" notification can also be done using the notify-osd. Since both these notifications don't require user interactions.

Charon (markus-lobedann) wrote :

I would really like to see this too, but have one further remark.

I think the best way to show this is to use notify-osd for the "wait"-notification, and just transform this into the "save removal"-notification when its ready. No need to show two notifications here.

cyberpython (cyberpython) wrote :

I agree, this can be really confusing sometimes - there have been cases where my usb drive has been unmounted and I kept waiting for some kind of response/notification from the system.

Ivanka Majic (ivanka) on 2009-06-17
Changed in hundredpapercuts:
status: New → Triaged
Martin Pitt (pitti) wrote :

Please note that this currently doesn't even work in Karmic, since we don't use gnome-mount any more, but gvfs talks to devicekit-disks directly. This should be discussed with upstream in a gvfs upstream bug preferably.

Changed in hundredpapercuts:
milestone: none → round-2
Åskar (olskar) wrote :

Corrrect me if I'm wrong but it wouldn't be possible to use the notification-OSD for the "wait"-message because the time a notificationbubble appears is hardcoded.

I think we should have the regular, current way of showing the progressbar while waiting and then pop up a message in a notificationbubble.

Vish (vish) wrote :

@ Askar
As of now notify-osd in jaunty still uses the same time for all bubbles...

But bubbles are planned to be given different intervals>

But as the Bubbles can transform/flow ... his behavior is seen when volume/brightness are adjusted , same could be done in for this...

Mirco Müller (macslow) wrote :

mac_v, again notify-osd is not in control of the notifications it's getting send, but the applications making use of the notifiaction service. In your request-case this would be gvfs.

Changed in notify-osd:
assignee: nobody → Mirco Müller (macslow)
importance: Undecided → Wishlist
status: New → Invalid

As pointed out in the comments, this is a larger upstream issue, not a trivial-to-fix paper cut.

Changed in hundredpapercuts:
milestone: round-2 → none
status: Triaged → Invalid
Vish (vish) wrote :

@ Mirco Muller: Hei..! I just noticed this one!
I had submitted this to the papercuts project *alone* , but someone else had it assigned to notify-osd! The notify-osd mention was the proposal of how to present the notifications... This aint my bad ;p the other one was!

Anyway... submitted request upstream.

Changed in gvfs:
importance: Undecided → Unknown
status: New → Unknown
Changed in gvfs:
status: Unknown → New
Changed in gvfs:
importance: Unknown → Medium
affects: notify-osd → notify-osd (Ubuntu)
Changed in gvfs:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
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.