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 719857 - autorunManager: Remove the resident "Removable Devices" notification
autorunManager: Remove the resident "Removable Devices" notification
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-12-04 17:59 UTC by Jasper St. Pierre (not reading bugmail)
Modified: 2021-07-05 14:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
autorunManager: Remove the resident "Removable Devices" notification (8.98 KB, patch)
2013-12-04 17:59 UTC, Jasper St. Pierre (not reading bugmail)
none Details | Review

Description Jasper St. Pierre (not reading bugmail) 2013-12-04 17:59:41 UTC
Users aren't usually the best at obeying the rules, and systems can
deal with hotplug without ejecting first.
Comment 1 Jasper St. Pierre (not reading bugmail) 2013-12-04 17:59:43 UTC
Created attachment 263522 [details] [review]
autorunManager: Remove the resident "Removable Devices" notification
Comment 2 William Jon McCann 2013-12-04 18:10:39 UTC
Putting this here for the record - as mentioned on IRC a few times.

My proposal was two part. The first part is to enhance the autorun to be aware of applications that can handle the device natively. So you would not get annoyed when you attach a camera while already in Photos. If not in an app that has the capability to handle the type of information/content on the device then prompt as usual with one difference: don't open a new copy of handler app but bring existing to the fore. So, for nautilus it would open in a tab.

The second part addresses the "resident" eject devices thing in the message tray. It is pointless to eject things when you are only reading. And it is bad that we can eject things out of band from handler app. It seems to me it is really only possibly necessary to eject explicitly when doing writes - to ensure writes are finished and flushed.

We should probably do some investigation to ensure those writes are flushed in a timely fashion and that the inconsistent state is indicated in handler app.

So, given that and the shell eject thing being really so far from the typical mental model as the user works within an app, I don't think it is useful to retain.
Comment 3 Giovanni Campagna 2013-12-05 17:58:20 UTC
(In reply to comment #2)
> Putting this here for the record - as mentioned on IRC a few times.
> 
> The second part addresses the "resident" eject devices thing in the message
> tray. It is pointless to eject things when you are only reading. And it is bad
> that we can eject things out of band from handler app. It seems to me it is
> really only possibly necessary to eject explicitly when doing writes - to
> ensure writes are finished and flushed.

As I said in IRC, it is not at all pointless to properly eject if you're just "reading". There is no such thing as just reading, unless you mount the FS readonly (which we don't do): depending on the filesystem and the mount options, reading operations can trigger a number of writes. For ext*, atime updates and the dirty journal bit are the first that come to my mind. Judging by how often it breaks, I guess FAT has some too, but I don't know for sure.
Comment 4 GNOME Infrastructure Team 2021-07-05 14:38:57 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.