Comment 18 for bug 1020759

This kind of "new behavior" which breaks everythink that was carefully configured before, annoys me as well. ("it's not a bug, it's a feature")

I'm using several applications (unison in particular) on external drives, and for them when I made my user configurations I made references to /media/<label>, not /run/media/<username>/<label>, not to /media/<username>/<label> (like Debian did)

It's especially annoying for tools such as Unison which have a database of all changes made on disks, and can't refer to the correct names because it was arbitrary changed, so you must forget all the previous history and build a new one, which is long and tedious for huge external drives.

Come on, who is ever using a Linux Desktop for several users, AND at the same time needs security so they can plug different usb keys or external drives simultaneously? In more than 99% of the cases, it won't be necessary, and in the rare cases it could be necessary (multiseat), this kind of behavior could be set as an option, for example in a damn /etc/udisks2.conf

On the other hand, if security was such an issue, /media/<username>/<label> could still have been kept, but the permissions for the folder could have been set in r/w only for the one who had inserted the key. After all, it doesn't prevent security to have /home/user1 and /home/user2 under the same folder.

For my part I could "fix" this by installing udisks (v1) and removing udisks2 and all its dependencies (including gnome, mate etc).

If you feel you really need to make a fondamental behavior change in a product, please use opt-in instead, and make an option to enable the new behavior, instead of the opposite.