staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

Es stimmt, dass die Schichten "oberhalb" von udisks, dieses nicht benutzen müssen und auch unabhängig von udisks mounten und die /etc/fstab auswerten können, wenn sie dazu den notwendigen Code mitbringen.

Das dies möglich ist, glaube ich gern. Aber ich habe keinerlei Beobachtungen gemacht, die ich darauf hin interpretieren könnte, dass dies hier wirklich geschieht. Ich gehe deshalb (naiv) davon aus, dass udisksctl -b und gio mount -d ausschließlich auf udisks2 zurückgreifen und dass für die beiden Frontends deshalb die dortige Reihenfolge und Einstellungen uneingeschränkt gelten.

Diese Beobachtung teile ich mit Dir genauso wie den Halbsatz von noisefloor

Würde mich zwar wundern,...

Ich wollte halt nur klarstellen, dass ich hier gegenüber anderen über kein gesichertes Wissen verfüge, sondern dass dies auf eben Deiner beschriebenen Beobachtung, plus der Hoffnung darauf, dass sich praktisch daran gehalten wird, beruht.

Und dieses "Konzept" dürfte hinter den meisten Aussagen im Wiki stehen, solange es nicht eine entsprechende eindeutige Dokumentation gibt, die man übernehmen könnte.

Also im Ergebnis dürften wir hier wohl wieder alle (mehr oder weniger) auf einer Linie sein.

LG, Newubunti

Also im Ergebnis dürften wir hier wohl wieder alle (mehr oder weniger) auf einer Linie sein.

+1 👍

Ich habe eine Bitte: Könnte jemand, der im NFS benützt, einmal probieren, ob gio mount nfs://… inzwischen funktioniert bzw., falls dies nicht der Fall ist, die Fehlermeldung posten? Ich habe kein NFS. Falls es funktioniert, findet man den Mountpunkt in /run/user/<UID>/gvfs.

Gruß – Max-Ulrich

Der im Artikel genannte Befehl

gio mount -d /dev/sdb1 

funktioniert so nicht immer, sondern nur, wenn die Gerätedatei auf etwas verweist, was bereits als "Volume" erkannt wurde.

Ich habe für einen beim Stecken nicht automatisch eingebundenen (was ich so haben will) USB-Stick:

$ ll /dev/sda*
brw-rw---- 1 root disk 8, 0 Mär 11 08:24 /dev/sda
brw-rw---- 1 root disk 8, 1 Mär 11 08:24 /dev/sda1
brw-rw---- 1 root disk 8, 2 Mär 11 08:24 /dev/sda2
$ gio mount -d /dev/sda1
gio: /dev/sda1: No volume for given ID

aber

$ udisksctl mount --block-device /dev/sda1
Mounted /dev/sda1 at /media/▒▒▒▒▒/Ventoy.
$ findmnt -t ntfs,ntfs3,exfat,vfat,msdos,fuseblk
TARGET              SOURCE    FSTYPE OPTIONS
/media/▒▒▒▒▒/Ventoy /dev/sda1 exfat  rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro

kB schreibt:

Der im Artikel genannte Befehl gio mount -d /dev/sdb1 funktioniert so nicht immer, sondern nur, wenn die Gerätedatei auf etwas verweist, was bereits als "Volume" erkannt wurde.

Das ist interessant und in sich ja konsequent.

Ich glaube nicht, dass es viele Benutzer gibt, für die der Unterschied eine Rolle spielt. Trotzdem ist ein kurzer Hinweis sicher kein Fehler. Ich werde diesen anbringen (falls du es nicht schon gemacht hast?).

Für mich ist unklar, was gio unter den Begriffen "mount" und "Volume" versteht. Offenbar ist hier "mount" nicht genau dasselbe wie für den Befehl mount und "Volume" ist das, was GProxyVolumeMonitorUDisks2 (also UDisks) als GProxyVolume meldet. Das ist mir aber zu technisch für das Wiki und wäre erst dann hilfreich, wenn man auch wüsste (und beschreiben könnte), wie man das steuern kann.

Genau so geht es mir auch. Der Befehl gio mount ist irgendwie schwammig und keineswegs identisch mit der Kernel-Routine mount. Ich stelle mir das so vor (ohne Garantie der Richtigkeit):

• bei lokalen Dateisystemen werden diese mittels udisk systemweit ins Dateisystem eingebunden und in /etc/mtab als eingebunden registriert. Sozusagen "der Weg ist anders, aber das Ziel das gleiche". Die "Hindernisse" auf beiden Wegen können sich unterscheiden.

• bei Remote-Dateisystemen ist das nochmal anders. gio mount hat mit mount nichts mehr zu tun, und auch das Ziel ist nicht das gleiche. Zunächst wird da überhaupt nichts "eingebunden", sondern nur der Zugriff ermöglicht (ähnlich wie z.B. bei smbclient), und die Syntax beim Zugriff ist auch nicht POSIX-konform.

• Um nun auch Anwendungen, die das so nicht mögen, den Zugriff zu ermöglichen, kann das GVfs (d.h. gio mount) aber wahlweise diese Dateisysteme auch mittels FUSE im Userspace zusätzlich noch einbinden. Dies geschieht über das GIO-Modul (Daemon) gvfsd-fuse im gleichnamigen Paket gvfs-fuse, das in Ubuntu (auch Xubuntu usw., eben GTK) zur Grundausstattung gehört. Nur dieses Modul bewirkt etwas, was mit mount Ähnlichkeit hat.

• Weil das Einbinden erst mit dem Modul und im Userspace passiert, wird bei gvfs mount das Dateisystem nicht als "systemweit eingebunden" in /etc/mtab registriert, wohl aber Modul gvfsd-fuse (bei NTFS-3G und Kollegen wird dort ja auch nur fuse bzw. fuseblk und nicht der Treiber NTFS-3G, nicht einmal der Dateisystem-Typ ntfs, eingetragen). Beispiel:

   gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

Ob das nun alles ganz genau stimmt und auch korrekt ausgedrückt ist, weiß ich nicht. Es ist mein persönlicher Versuch, mir in dem Gewirr etwas Klarheit zu verschaffen. Wie KDE es macht, weiß ich nicht.

Gruß, M.-U.

kB schrieb:

Für mich ist unklar, was gio unter ... und "Volume" versteht.

Zum Begriff "Volume":

https://wiki.gnome.org/Projects/gvfs/doc#Volume_monitors

und eventuell auch noch

https://gitlab.gnome.org/GNOME/gvfs/raw/master/monitor/udisks2/what-is-shown.txt

LG, Newubunti

Newubunti schrieb:

[…] Zum Begriff "Volume":

https://wiki.gnome.org/Projects/gvfs/doc#Volume_monitors

Danke für den Link! Ich habe ihn in die Link-Liste des Artikels aufgenommen.

Er enthält am Anfang eine bemerkenswerte Anmerkung:

GVfs provides several implementations of those (hal, gdu, udisks2) and only one can be active.

Da wir schon wissen, dass bei Ubuntu GVfs UDisks2 benutzt, wissen wir jetzt auch, dass es nur dieses benutzt.

und eventuell auch noch

https://gitlab.gnome.org/GNOME/gvfs/raw/master/monitor/udisks2/what-is-shown.txt

Danke auch hierfür. Das schaue ich mir noch im Detail an.

Hallo,

Er enthält am Anfang eine bemerkenswerte Anmerkung:

Wobei HAL ein Artefakt aus alten Zeiten sein muss. HAL ist mit 10.04 (!) aus Ubuntu entfernt worden, DeviceKit ist der Nachfolger. Gut, in der Linux-Welt findet sich ja immer irgendwer, der stark an alter Technologie hängt, aber AFAIK ist HAL seit > 10 Jahren irgendwo zwischen tot und obsolet.

Was ist "gdu" in dem Kontext finde ich den "gvfs-gdu-volume-monitor", aber in erster Linie in Threads und Bugreports, die auch > 10 Jahre alt sind.

Gruß, noisefloor

GVfs provides several implementations of those (hal, gdu, udisks2) and only one can be active. Da wir schon wissen, dass bei Ubuntu GVfs UDisks2 benutzt, wissen wir jetzt auch, dass es nur dieses benutzt.

Wir wissen das natürlich, aber ich will es trotzdem nochmal betonen, damit wir nicht Aussagen machen, die missverstanden werden könnten: Hier handelt es sich ausschließlich um das Einbinden lokaler Dateisysteme (Befehl gio mount -d…). Da wird wohl nur udisks2 verwendet; all das andere ist, wie noisefloor schreibt, obsolet. Alle andere locations ("Orte") haben mit udisks2 nichts zu tun.

Ich darf wohl wieder etwas "ins Unreine" reden: Das GVfs ist für mich ein Konglomerat von verschiedenen Routinen, die mit verschiedenen Backends von verschiedenen Ausgangspunkten ausgehen und die alle dann Dateimanager-gerecht zusammenführen. Wenn man so sagen darf, ein konvergierendes Bündel von verschiedenartigen Routinen. Doch hoffentlich schreibt das niemand so ins Wiki! 😕