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 430024 - External/removable ESATA/SATA drives should be treated more like USB/Firewire
External/removable ESATA/SATA drives should be treated more like USB/Firewire
Status: RESOLVED WONTFIX
Product: gnome-vfs
Classification: Deprecated
Component: Volume and drive handling
2.16.x
Other All
: Normal minor
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2007-04-15 16:09 UTC by Dan S.
Modified: 2018-08-17 13:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Dan S. 2007-04-15 16:09:43 UTC
I've been using an ESATA drive for a while now with a cheap PCMCIA interface card. This setup has been fantastic for data-intensive applications.

However, setting it up to act more like the "external drive" that it is seems impossible. I've given up on being able to mount it like I would a USB drive and have to pmount/pumount from the command line.

The closest I've gotten is by adding '/dev/disk/by-label/extdrive ... noauto,user' to fstab. This lets me mount from Nautilus, but I cannot unmount from nautilus: it shows an unmounted status in "Computer" and just tries (and fails) to mount it again if I double-click.

If I use "LABEL=" or "UUID=" in fstab, I can't mount it, period.

Overall I've been able to get things working well enough for me to get stuff done with the drive.

However it would be much nicer if there was a method to indicate that a specific SATA drive (or, better, perhaps some/all SATA ports on a controller?) are "removable", and to have the user experience for those volumes be more like a USB drive.

That would cover my situation nicely, but also be very handy for people who have drive caddies in their dekstop and want swap them out on the fly.

Other information:
Comment 1 simon80 2008-03-29 23:57:11 UTC
This also affects me, in GNOME 2.20.1.
Comment 2 Martin von Wittich 2009-01-17 21:45:47 UTC
Me too. At least in Ubuntu/Debian this could be caused by the file /usr/share/hal/fdi/policy/10osvendor/debian-storage-policy-ignore-fixed-crypto-drives.fdi:

<deviceinfo version="0.2">
  <device>
    <match key="volume.fsusage" string="crypto">
      <match key="@block.storage_device:storage.hotpluggable" bool="false">
        <match key="@block.storage_device:storage.removable" bool="false">
          <merge key="volume.ignore" type="bool">true</merge>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>

I looked through lshal and my eSATA crypto disk (/dev/sda) has the necessary conditions set (volume.fsusage=crypto,storage.hotpluggable=false,storage.removable=false), while /dev/sda1 (the encrypted partition) has volume.ignore set. I believe one could override this through /etc/hal/fdi/policy/preferences.fdi, but I have not yet figured out yet how.
Comment 3 simon80 2009-01-19 00:57:43 UTC
It's not the file's fault: storage.hotpluggable and storage.removable should both be true, but are false.
Comment 4 Martin von Wittich 2009-01-19 09:51:11 UTC
You're right, at least storage.hotpluggable should AFAIK be true for all SATA drives when using AHCI. But which drives should have storage.removable = true? One can't differentiate between internal disks connected to SATA ports and external disks connected to the very same SATA ports (by using an eSATA bracket)...
Comment 5 André Klapper 2018-08-17 13:51:25 UTC
gnome-vfs got deprecated in 2008.

gnome-vfs is not under active development anymore and had its last code changes
in 2011. Its codebase has been archived:
https://gitlab.gnome.org/Archive/gnome-vfs/commits/master

gio (in glib) and gvfs are its successors. See https://developer.gnome.org/gio/stable/ch33.html and https://people.gnome.org/~gicmo/gio-migration-guide/ for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent + supported version of glib/gio/gvfs. Thanks!