The move from /media to /run/media/$USER has resulted in the creation of the following bug.... 1. Insert a removable device. 2. Wait for it to be mounted. 2. Reboot your system. 3. Log back in again. 4. The device is invisible. This is not expected behavior. This is not intuitive behavior. This is not the behavior of any other OS currently in existence, as far as I know. If I log in, I expect the removable devices in my system to be visible to me. They were visible in F16. They whould be visible in F17.
(In reply to comment #0) > The move from /media to /run/media/$USER has resulted in the creation of the > following bug.... > > 1. Insert a removable device. > 2. Wait for it to be mounted. > 2. Reboot your system. > 3. Log back in again. > 4. The device is invisible. > > This is not expected behavior. This is not intuitive behavior. This is not the > behavior of any other OS currently in existence, as far as I know. > > If I log in, I expect the removable devices in my system to be visible to me. > They were visible in F16. They whould be visible in F17. I think you are confused. The main change is that GNOME does not auto-mount devices at login anymore and that's not a bug, it's actually by design. And the device is not "invisble" just because it's not mounted - you can get to it by clicking its icon in the file manager (nautilus / Files) or the file chooser. If you insist on the device being mounted at OS start-up, you can add an /etc/fstab entry (the "Edit Mount Options" dialog of the Disks can be used to do that). There is no bug here so closing NOTABUG.
Your logic for why this is not a bug is circular. You are claiming that it is not a bug because the behavior is by design. I am saying that it is that design that is buggy. Windows: Log in. Open cmd window "cd d:". Oh, look, there are my files! Mac OS: Log in. Open terminal window. "cd /Volumes/...". Oh, look, there are my files! F17 GNOME: Log in. Open terminal window. Where are my files? It strains credulity to say that it makes any sense whatsoever for a device to be mounted when I am logged in, and then if I immediately log out and log back in again, it's no longer mounted. There is a huge infrastructure built into GNOME to restore a user's session to how it was when he logged out. Why this should be any different is beyond me. I know the etiquette, so I'm not going to reopen the ticket even though I think this is an incredibly stupid, non-intuitive design change which is just plain wrong. It'll be interesting to see how many dupes, CC's and votes this ticket gets after F17 is released.
As I explained, GUI users can easily access their files simply by using the UI (that is: the file manager or the file chooser) even when the device is not mounted. IOW: they're fine. This is by far most GNOME users. Non-GUI users with needs to access a device at a known path at log-in time ("experts" or "Linux hobbyists" or whatever), such as yourself... you guys are expected to actually know enough about the system to be able to use things like the /etc/fstab file... which has been around since the dawn of time ... or write a script to mount your devices... or whatever. Note that /etc/fstab also allows you to precisely control the mount path, mount path permissions and mount options. It allows you to use constructs such as the /dev/disk/by-* symlink forst and so on. Also: The Disks application even includes an UI for editing /etc/fstab entries, see http://davidz25.blogspot.com/2012/03/simpler-faster-better.html and http://git.gnome.org/browse/gvfs/tree/monitor/udisks2/what-is-shown.txt for more details about what you can control. You remarks and use words is not exactly helping your cause here. Good luck.
David, do you seriously think that "finding the device" is discoverable? I hate to bring up such cliches as Aunt Tilly, but I am with Jonathan here: this is not only different from the previous Fedora releases, but also inconsistent with other operating systems. The users that I support for a living look for their files. They are not Linux hobbyists or experts, they are mathematicians wanting to use a Latex and math friendly environment but they do not know much about Linux. If they happen to plug in their USB stick but only then discover that they had not in fact actually turned on their PC, now they have to know that the device is actually "LEXAR 8 GB" instead of "SONY SMARTCARD READER". Do you think that is the case you want to support?
OK, I think you guys changed my mind. I mean, it doesn't really make things worse for anyone if we automount at login time and since it arguably makes things a little better for some, let's just do it and avoid this behavioral change. I fixed the bug upstream here http://git.gnome.org/browse/gvfs/commit/?id=e30a67f3215d829e95ee7e358c67af7d67635fe8 I'm reopening and reassigning to GVfs ... the GVfs package maintainers can close this bug once that patch lands downstream.
Adjusting summary to be a bit more accurate
Got mid-air-collisioned, but for reference: Issues with the (prior) design: 1) By placing them in a user-specific directory, it implies that mounts are tied to the session. However, they are not - they persist beyond it until reboot. This leads to inconsistency - you log in once, plug in a device. Then, if you log out and log back in a week later, the device is there, when it wouldn't be if all you did was reboot the machine in the interim. 2) /run/media/user/$foo is odd, given that we already have /run/user/$foo waiting to be used. (This ties into #1, although not directly related.) 3) The disks default for mount point naming doesn't match the gvfs/udisks2 default for in session 4) It's inconsistent with other uses of detachable hardware. For this, if it's coldplugged (booted with attached), it's visible-in-gvfs-but-inactive in all sessions unless someone activates it. For other detachable hardware, such as a USB webcam, it's immediately active when booted coldplugged. (I understand there are reasons why that works better, but it's still inconsistent.) It would seem to me a better design would be for it not to automount at all, but on both hotplug and coldplug to be shown as a device in the notification area much as it is now, with the same options that are normally shown with hotplug. In this case 'Open With Files' would mount and then open, rather than operating on an already mounted filesystem.
(In reply to comment #7) > 2) /run/media/user/$foo is odd, given that we already have /run/user/$foo > waiting to be used. (This ties into #1, although not directly related.) We actually started out using /run/user/$foo/media but... there's a bunch of security issues with having a privileged process mount a device in a directory that is under the control of the untrusted process we mount on behalf of... > It would seem to me a better design would be for it not to automount at all, > but on both hotplug and coldplug to be shown as a device in the notification > area much as it is now, with the same options that are normally shown with > hotplug. In this case 'Open With Files' would mount and then open, rather than > operating on an already mounted filesystem. That's an interesting design (and I think, generally something that would make the unix-diehard-beards put a contract on you...). However, part of the user interaction requires sniffing the files on the device ... for example to see if there are photos on it and if so, prompt the user to import them. Of course, we could then unmount the device _right after sniffing but..
Plus, it's still not very nice for the case where I just want to plug in a USB stick and then do something with it at the console. It gives me the choice between having the device mounted but also having a Nautilus window open which I didn't want, or having no extraneous Nautilus window, but not having the device mounted... It really is kind of annoying to plug in a stick, do 'ls /media/<tab>', and get crickets. Thanks for the change, David. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
gvfs-1.12.2-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/gvfs-1.12.2-1.fc17
Package gvfs-1.12.2-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing gvfs-1.12.2-1.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6873/gvfs-1.12.2-1.fc17 then log in and leave karma (feedback).
gvfs-1.12.2-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.