udisks and eSATA: a question about the meaning of "detachable"

Phillip Susi psusi at cfl.rr.com
Tue Jul 12 13:57:47 PDT 2011

On 7/12/2011 3:57 PM, David Zeuthen wrote:
> As I've already explained GNOME does this for devices connected via
> USB/Firewire (99% of all flash readers) or for devices specifically
> tagged as being flash readers (covering flash readers connected via
> SDIO). So it's fine, GNOME is doing the right thing here for 99.9% of
> all users.

I am aware of the current situation.  Based on discussions with various 
people over the last year or two ( including Key Sievers and Martin Pitt 
), I thought it was now well understood that GNOME needs to go away from 
making that assumption based on the disk being USB or Firewire.

> You would think so, sure. But as I already explained, this is not the
> case - people use GNOME everywhere even on servers and people don't
> tend to install the right variant of the distro. We just can't
> automount the world willy-nilly, sorry.

I would think that a server admin in such a comparatively VERY rare 
setup could be bothered to change the system policy to disable automount 
( which is generally not something you want servers to do ever, whether 
it be on the SAN or a USB disk ).  Leaving it enabled by default makes 
sense for the vast majority of cases, and simply extends the current 
behavior to include eSATA and other future interfaces.

So far the only use case I can see where you do not want to auto mount 
the world willy-nilly is this contrived case of a server attached to a 
SAN and having a desktop environment installed.  This case has got to be 
at least two orders of magnitude more rare than desktop users with eSATA 
disks that DO expect them to be auto mounted.

> And, here's the thing, we _don't_ need to automount the world that
> because the current limited whitelist consisting of USB/Firewire/Flash
> is already working fine for 99.9% of all users. And when it's not
> working, the user can now tweak it himself using UDISKS_AUTOMOUNT_HINT
> (if he even cares). If it's for a popular kind of device we can even
> ship that udev rule with upstream udisks.

There is no reliable way to differentiate between internal and external 
sata disks, so saying "write a udev rule to handle them" doesn't work.

> Btw, your socalled "desktop distribution" can just set
> UDISKS_AUTOMOUNT_HINT=always for every device if they so desire - it's
> a simple udev rule. But I wouldn't recommend doing this.

A flag you can set to override the broken behavior misses the point that 
the built in behavior is broken.

> As a rule of thumb, sure, it's never good to rely on heuristics,
> connection bus types, protocol types and whitelists. But it's just not
> that black/white and if data-loss can happen, as it can and _will_ if
> you just blindly automount filesystems, I'd rather err on the side of
> not losing data.

Besides the hybrid desktop/server on the SAN, where else could you run 
into trouble auto mounting a disk that shows up at run time?

More information about the devkit-devel mailing list