First let me explain how this is supposed to work so we can point people / distros to this bug:

 - We only show mounts in /media and $HOME (excluding $HOME/.gvfs)
 - We attempt to mount everything that gets shown as a volume
 - We only show volumes if there's a mountable filesystem
   - Except if an entry in /etc/fstab point to it (see also bug 520851)
   - Or if hal's volume.ignore is set to TRUE
   - On most distros this is locked down for internal drives
     either via volume.ignore for all internal drives (so they
     are hidden) or, these days, via PolicyKit (the action / authorization
     is called org.freedesktop.hal.storage.mount-fixed) so e.g. partitions
     can't be mounted without authenticating

This is intended behavior and here's why:

 - It's relatively easy to explain to users ("you don't want to see
   an icon for /dev/sda2? Just create an /etc/fstab entry pointing to
   outside /media")

 - In general if you have mountable filesystems you want to see them

 - In particular you want to see Windows and OS X file systems

The only problem occurs for users that has multiple Linux distributions installed. My take on this is very simple: If you're in that boat then you know how to create /etc/fstab entries (or even hal fdi files with volume.ignore!).

Me? Personally I like being able to see a volume "Fedora 8" when I'm running Rawhide on this dual-boot system containing Fedora Rawhide and Fedora 8. There's a couple of actions I'd like to see distributions making

 - Set sane labels on filesystems by default
   - e.g. "Fedora 8" instead of "/12"
   - Fedora https://bugzilla.redhat.com/show_bug.cgi?id=364441

 - Don't mount-by-label, mount by UUID so the user can change the fs
   label of a volume
   - Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=364451

 - Avoid creating more than one partition with file systems; e.g.
   a /usr and a / partition. If you do then please use sane labels
   such as "Fedora8 /usr" etc. At least on laptop installs that
   is what most people use.
   - it's still fine to have swap partitions; we don't show these
     in the UI anyway

Hope this clarifies this is intended behavior and not a bug.

[1] : Historically the reason some distros (including Fedora)
      do silly things like asking for the root password to do such
      a mundane thing as mounting a Windows or OS X file system
      is simply because one cannot know in advance how people will
      use the OS. E.g. Fedora is a general purpose OS that is used
      both on laptops and also on boxes with 10,000 disks and 4,000
      CPU's. On such systems we really don't want to mount all these
      disks. [2]

[2] : That's why, for Fedora [3], that our installable desktop live
      cd will probably allow an authorization for mounting fixed
      drives out of the box. If someone installs it to a server
      with 10,000 disks it's their own fault... they should have
      used the server edition or general purpose install media.

[3] : I'm using Fedora only as an example here. Hope it's clear how
      it applies to any distribution.

Hm, I don't quite agree here. I do not think it is a good idea to automatically mount internal partitions "just because we can". We don't have any fsck integration, so if you by chance mount any corrupted partition several times, you're only going to make it worse. Also, personally I have a lot of test partitions which I do not want to see, it utterly clutters my desktop, and I never actually need them.

That aside, that's how I think it should work:

 * storage.automount_enabled_hint is a defined hal property [1] which gvfs should follow. If it is false, then it should not automount.

 * The hal upstream default is to not set storage.automount_enabled_hint anywhere, so that wouldn't change the behaviour you describe. However, distros, users, and system administrators would have a standard way to modify the mount policy.

So, this bug is not about changing the default policy (where, as you point out, one can argue one way or the other), but ignoring automount_enabled_hint.

Thank you for considering!

[1] http://people.freedesktop.org/~david/hal-spec/hal-spec.html#device-properties-storage

(In reply to comment #2)
> Hm, I don't quite agree here. I do not think it is a good idea to automatically
> mount internal partitions "just because we can". We don't have any fsck
> integration, so if you by chance mount any corrupted partition several times,
> you're only going to make it worse.

By the same token we shouldn't mount anything at all! To put it in another way: If some of the file system drivers really are that much crap then maybe these file system drivers shouldn't be enabled by default. But I see your point (and, sure, ntfs / hfs+ drivers probably are not of same quality as ext3). Then again, distros shouldn't be shipping crap in the default install. But I digress.

> Also, personally I have a lot of test
> partitions which I do not want to see, it utterly clutters my desktop, and I
> never actually need them.

In that case I think you fall into the group of users we can expect to set up either /etc/fstab or write an fdi file that sets volume.ignore on these...

> That aside, that's how I think it should work:
> 
>  * storage.automount_enabled_hint is a defined hal property [1] which gvfs
> should follow. If it is false, then it should not automount.

Fine with me, we already have g_volume_should_automount(), just need to plug that into hal/ghalvolume.c's implementation of that function. Can you look into doing this? Probably need to get release team approval if you want it into 2.22 instead of as a vendor patch.

>  * The hal upstream default is to not set storage.automount_enabled_hint
> anywhere, so that wouldn't change the behaviour you describe. However, distros,
> users, and system administrators would have a standard way to modify the mount
> policy.

Right. I'm fine with this. It's not a bad idea. Probably not something I'd enable in Fedora's desktop live cd though.

> In that case I think you fall into the group of users we can expect to set up
> either /etc/fstab or write an fdi file that sets volume.ignore on these...

Heh, indeed. I just try to stay at the defaults, dogfooding and such. Historically, distros haven't mounted internal disks by default, and I'm a bit hesitant to change this now. Maybe I just need to get used to the new world :)

> Fine with me, we already have g_volume_should_automount(), just need to plug
> that into hal/ghalvolume.c's implementation of that function. Can you look into
> doing this?

Yes, I will create a patch and attach it here. I just wanted to get an agreement before.

Thanks,

Martin

Created attachment 106790 [details] [review]
Ubuntu patch

This is the patch I added to the Ubuntu package to fix this bug.

With the default hal it still automounts internal partitions. If I add this to /etc/hal/fdi/policy/preferences.fdi, it suppresses automount:

  <device>
    <match key="storage.hotpluggable" bool="false">
      <match key="storage.removable" bool="false">
        <merge key="storage.automount_enabled_hint" type="bool">false</merge>
      </match>
    </match>
  </device>

Commited.

(In reply to comment #1)
> [...]
>  - We only show mounts in /media and $HOME (excluding $HOME/.gvfs)
> [...] 

Is there already a possibility to blacklist mounts in $HOME for this purpose? I have a bunch of partitions mounted via /etc/fstab to directories in $HOME and I don't want them to crowd 'Computer' and 'Places > Removable Media'.

Thanks!

Exactly.

I have /home/maxim/software  and want to put it on seperate partition
(someday maybe even a disk)

But I don't like it being shown on desktop...

I'm sorry.

The status now is RESOLVED FIXED.

But, do we have a easy-to-access GUI to do the settings as the patch does?

GNOME and Nautilus is for `average` users, right?