staging.inyokaproject.org

Hallo kB,

im Abschnitt Baustelle/Windows-Partitionen einbinden (Abschnitt „Treiber-festlegen“) steht:

Wer exfat-fuse einsetzen möchte, sollte ein automatisches Laden des Kernel Moduls exfat verbieten, indem man es auf die Sperrliste setzt. Außerdem kann man, damit für den Dateisystemtyp exFAT das zuständige Programm direkt gefunden wird, einen symbolischen Link setzen: ...

Ich muss diesen Link setzen, wenn ich das Laden des Kernelmoduls verhindere, andernfalls erhalte ich eine Fehlermeldung, dass exfat-fuse ein dem Kernel unbekanntes Dateisystem ist.

Der Abschnitt Baustelle/Windows-Partitionen einbinden (Abschnitt „Automatisches-Einhaengen“) ist Wiki-technisch prädestiniert in Zukunft zu veralten, womit er dann Verwirrung stiften könnte. Wäre es hier nicht besser, für die Standards auf die Datei /etc/udisks/mount.options.conf.example zu verweisen. Also:

In der Praxis werden beim automatischen Einhängen (mittels UDisks) ohne eigene Konfiguration die in der Datei /etc/udisks2/mount.options.conf.example aufgeführten Standards verwendet.

Falls die Beispiele bestehen bleiben sollen, dann würde ich diese aber als Beispiele aus Version ... kennzeichnen, mit dem Hinweis, dass sich diese Standards künftig ändern können.

Außerdem würde ich bei

Anders als bei den Kernel Modulen erhalten aber auch alle anderen Vollzugriff.

noch ergänzen, dass aber aufgrund der Rechtesetzung des übergeordneten Verzeichnisses /media/$USER praktisch trotzdem nur der einbindende Nutzer Zugriff auf das an sich für jeden nutzabre Dateisystem erhält.

Im Abschnitt Baustelle/Windows-Partitionen einbinden (Abschnitt „Praxis-der-Einbindung“) heißt es:

Jeder Benutzer kann in der Datei fstab mit der Option user oder users eingetragene Dateisysteme mit dem Befehl mount^[1] einhängen. Bei den mit FUSE einzuhängenden Dateisystemen wie z.B. exfat-fuse und ntfs-3g ist ab Ubuntu 22.04 eine solche Markierung mit user oder users nicht mehr erforderlich. Siehe Hinweis unten.

Welcher "Hinweis unten" ist denn da gemeint?

Überhaupt kann ich die Gleichsetzung im Praxisteil von exfat-fuse und ntfs-3g nicht nachvollziehen.

Die Optionen user und users funktionieren bei mir für exfat-fuse unter 22.04.X und 24.04 wie erwartet, sobald alleine das SUID Bit für /usr/sbin/mount.exfat-fuse gesetzt ist.

Die Expertenbox finde ich daher hinsichtlich exfat-fuse mindestens irreführend, weil sie den Leser auch hinsichtlich exfat-fuse dazu verleiten kann, mehr Rechte einzuräumen, als eigentlich notwendig.

LG, Newubunti

Newubunti schrieb:

[…]

Ich habe die meisten Deiner Punkte eingearbeitet:

[…]

Wer exfat-fuse einsetzen möchte, […] kann […] einen symbolischen Link setzen: ...

Ich muss diesen Link setzen, […]

OK

[…] die in der Datei /etc/udisks2/mount.options.conf.example aufgeführten Standards

ÖK

[…] als Beispiele aus Version ... kennzeichnen

OK

[…] ergänzen, dass aber aufgrund der Rechtesetzung des übergeordneten Verzeichnisses /media/$USER praktisch trotzdem nur der einbindende Nutzer Zugriff auf das an sich für jeden nutzabre Dateisystem erhält.

OK

[…]

Jeder Benutzer kann in der Datei fstab mit der Option user oder users eingetragene Dateisysteme mit dem Befehl mount^[1] einhängen. Bei den mit FUSE einzuhängenden Dateisystemen wie z.B. exfat-fuse und ntfs-3g ist ab Ubuntu 22.04 eine solche Markierung mit user oder users nicht mehr erforderlich. Siehe Hinweis unten.

Welcher "Hinweis unten" ist denn da gemeint?

Der Hinweis war ursprünglich der vorstehende Satz, auf den natürlich jetzt hier ein Verweis unsinnig ist.

Überhaupt kann ich die Gleichsetzung im Praxisteil von exfat-fuse und ntfs-3g nicht nachvollziehen.

Erläutere das bitte genauer. Aus meiner Sicht besteht eine Gleichsetzung nur in der Hinsicht, dass beide FUSE-Programme sind. Die Ergebnisse nach der Einbindung eines Dateisystems unterscheiden sich zwischen den beiden Typen, wie auch im Text dargestellt.

Die Optionen user und users funktionieren bei mir für exfat-fuse unter 22.04.X und 24.04 wie erwartet, sobald alleine das SUID Bit für /usr/sbin/mount.exfat-fuse gesetzt ist.

Das widerspricht meinen Experimenten. Ich überprüfe das aber noch einmal.

Die Expertenbox finde ich daher hinsichtlich exfat-fuse mindestens irreführend, weil sie den Leser auch hinsichtlich exfat-fuse dazu verleiten kann, mehr Rechte einzuräumen, als eigentlich notwendig.

Ich überprüfe das nochmal, jetzt mit in der Regel hilfreichem zeitlichen Abstand zu der geführten heftigen Diskussion.

kB schrieb:

Newubunti schrieb:

[…]

[…]

Die Optionen user und users funktionieren bei mir für exfat-fuse unter 22.04.X und 24.04 wie erwartet, sobald alleine das SUID Bit für /usr/sbin/mount.exfat-fuse gesetzt ist.

Das widerspricht meinen Experimenten. Ich überprüfe das aber noch einmal.

Die Optionen user & Co. sind nur relevant für die Benutzung des Programms mount durch normale Benutzer, also mit einer vorbereiteten Zeile in /etc/fstab und folgendes gilt auch nur explizit für exfat-fuse, die Erwartungen an die Option user lt. Manpage sind:

1. Es werden als Nebeneffekt die Optionen nodev,nosuid,noexec gesetzt.

2. Jeder normale Benutzer darf mount mit dieser Zeile benutzen.

Die zweite Erwartung ist obsolet mit der Änderung in libmount ab Ubuntu 22.04; FUSE-Programme benötigten die Option user nicht mehr.

Hinsichtlich der ersten Erwartung ist das Ergebnis eines Einbindeversuchs völlig unabhängig von einer Angabe der Option user, man erhält immer nosuid,nodev,relatime.

Also: user ist bei exfat-fuse wirkungslos; es wird ignoriert wie etliche andere Optionen auch. Immerhin ist es nicht in manchen Situationen schädlich wie bei ntfs-3g.

Damit exfat-fuse mit mount funktioniert, muss es allerdings als root laufen. Man muss also selbst root sein oder das SUID-Bit muss für das Programm gesetzt sein.

Das kann man alles vergessen, wenn man einfach udisksctl statt mount benutzt.

Die Expertenbox finde ich daher hinsichtlich exfat-fuse mindestens irreführend, weil sie den Leser auch hinsichtlich exfat-fuse dazu verleiten kann, mehr Rechte einzuräumen, als eigentlich notwendig.

Ich überprüfe das nochmal, jetzt mit in der Regel hilfreichem zeitlichen Abstand zu der geführten heftigen Diskussion.

Ich habe die Expertenbox erweitert, um auf diesen Umstand hinzuweisen.

Artikel ist nun wieder im Wiki.

Bei NTFS kann diese bestehende Verbindung zu einem anderen Betriebssystem erkannt werden; Linux verweigert dann eine Einbindung mit Schreibzugriff und bindet im Lesemodus (ro) ein.

Dies gilt AFAIK nur, wenn man bei einer bestehenden Verbindung versucht, die Windows-Systempartition in Linux einzubinden. Bei allen anderen NTFS-Partitionen erkennt Linux die bestehende Verbindung nicht (wie sollte dies auch gehen?), und sie werden rw eingebunden. Dies ist aber trotzdem nicht immer harmlos. (der Hinweis auf c: am Ende des Absatzes sagt dies zwar auch, aber nicht so deutlich)

oder man kann bekannte Dateisysteme in fstab^[2] eintragen. Insbesondere beim Dateisystemtyp NTFS kann dies für eine ordnungsgemäße Funktion erforderlich sein.

Zumindest beim Treiber NTFS3 ist es unbedingt zu empfehlen, dies nur mit der zusätzlichen Option nofail zu tun, da es sonst sehr leicht geschehen kann, dass das System nach einem ungeregelten Shutdown oder Absturz nicht mehr bootet (siehe Hinweis in NTFS3)!

FAT wird nahezu immer unterstützt, erlaubt aber nur kleine Dateien unter 2 GiB.

Meines Wissens sind das 4 GB, und so ganz "kleine" Dateien sind dies doch nicht (?)

Nur relevant für die selten verwendete Variante lowntfs-3g von ntfs-3.

Wohl nur Tippfehler: … von ntfs-3g.

Temporär simulierte Dateirechte … Temporärer Besitzer des Dateien wird, sofern nicht explizit etwas anderes festgelegt wird. der Besitzer des Prozesses, welcher die Einbindung durchführt.

Hier wäre vielleicht ein Hinweis auf die URL http://storaged.org/doc/udisks2-api/latest/mount_options.html (seit Kernel 6.xx) hilfreich. Dort findet man die für udisks2 gültigen Voreinstellungen für alle Treiber und auch die jeweils zulässigen individuellen Einstellungen. Wird das Einbinden hingegen durch einen Eintrag in fstab mit noauto vorbereitet, so ist (zumindest bei NTFS3) immer Root und nicht der Besitzer des Einbindungsprozesses scheinbarer Eigentümer, wenn dort für uid und gid nichts anderes eingetragen ist.

Unter Winwows ist diese Betriebsart immer aktiviert, unter Linux ist sie standardmäßig ausgeschaltet. (betr. windows_names)

Dies stimmt für mount und für fstab-Einträge. Bei udisks2 und damit auch beim Einbinden per GUI ist sie jedoch standardmäßig eingeschaltet.

Mit der Angabe ntfs selektiert man hier faktisch ntfs-3g. (steht bei UDisks bzw. udisksctl).

Im Gegensatz zu mount bzw. fstab wird bei UDisks der Treiber NTFS3 und nicht NTFS-3G selektiert, wenn man ntfs angibt.

Ich bitte um Entschuldigung, dass ich mit diesen Anmerkungen jetzt erst so spät komme. Ich konnte leider in letzter Zeit die Diskussion nicht lückenlos mitverfolgen.

Gruß, Max-Ulrich

Max-Ulrich_Farber schrieb:

Bei NTFS kann diese bestehende Verbindung zu einem anderen Betriebssystem erkannt werden; Linux verweigert dann eine Einbindung mit Schreibzugriff und bindet im Lesemodus (ro) ein.

Dies gilt AFAIK nur, wenn man bei einer bestehenden Verbindung versucht, die Windows-Systempartition in Linux einzubinden.

Jein. NTFS hat jedenfalls Mechanismen, über die man die Nutzung des Dateisystems in einem anderen Betriebssystem erkennen kann, z.B. das famose Dirty-Bit. Wobei ich nicht weiß, ob dieses hier zur Anwendung kommt oder ein anderer Mechanismus greift. Jedenfalls: Wenn Dirty, dann wird ro eingebunden, außer man zwingt Linux zu anderem Verhalten.

Bei allen anderen NTFS-Partitionen erkennt Linux die bestehende Verbindung nicht (wie sollte dies auch gehen?)

Grundsätzlich genauso. In der Praxis geschieht das möglicherweise deshalb nicht, weil Windows vor dem Schlafengehen die reinen Datenlaufwerke sauber aushängt und nur das Systemlaufwerk in diesem Schwebezustand belässt?

und sie werden rw eingebunden. Dies ist aber trotzdem nicht immer harmlos. (der Hinweis auf c: am Ende des Absatzes sagt dies zwar auch, aber nicht so deutlich)

So ist es. Und er sagt, dass man sich auf solche Mechanismen nicht verlassen soll, sondern selber sauber arbeiten möge. Besonders wenn man so gefährliche Dinge wie NTFS und Windows anfasst.

Max-Ulrich_Farber schrieb:

[…]

oder man kann bekannte Dateisysteme in fstab^[2] eintragen. Insbesondere beim Dateisystemtyp NTFS kann dies für eine ordnungsgemäße Funktion erforderlich sein.

Zumindest beim Treiber NTFS3 ist es unbedingt zu empfehlen, dies nur mit der zusätzlichen Option nofail zu tun, da es sonst sehr leicht geschehen kann, dass das System nach einem ungeregelten Shutdown oder Absturz nicht mehr bootet (siehe Hinweis in NTFS3)!

Das ist zwar inhaltlich richtig, hat aber gar nicht mit NTFS oder anderen Windows-Dateisystemen zu tun, sondern beruht auf der grundsätzlichen Rolle von fstab beim Systemstart. Diese Datei benennt die für eine ordnungsgemäße Funktion zwingend benötigten Dateisysteme. Wenn diese nicht eingebunden werden können, gibt es eben wie vorgesehen Kernel-Panik, außer man kennzeichnet die nicht zwingend benötigten Dateisysteme eben mit noauto, oder nofail oder errors=remount-ro (nicht bei allen Dateisystemtypen möglich) oder behandelt den Fehler anders. Auch ein defektes ext4 oder jeder andere Typ kann ohne ordentliche Fehlerbehandlung der Rechnerstart verhindern.

FAT wird nahezu immer unterstützt, erlaubt aber nur kleine Dateien unter 2 GiB.

Meines Wissens sind das 4 GB, und so ganz "kleine" Dateien sind dies doch nicht (?)

< 4 GiB, OK. Jeder, der real diese Beschränkung erfährt, wird 4 GiB als unpraktikabel klein empfinden. Viele, die sie nicht tatsächlich erfahren, dafür aber die Reaktion des Betroffenen im Forum lesen, werden möglicherweise dessen Reaktion mit einer unangebrachten Erwartungshaltung beschreiben. Tatsächlich sind 4 GiB in Zeiten, in denen man Laufwerke mit 4 TB vom Grabbeltisch fischt, kleine Dateien: ca. 1‰

Nur relevant für die selten verwendete Variante lowntfs-3g von ntfs-3.

Wohl nur Tippfehler: … von ntfs-3g.

OK.

Temporär simulierte Dateirechte … Temporärer Besitzer des Dateien wird, sofern nicht explizit etwas anderes festgelegt wird. der Besitzer des Prozesses, welcher die Einbindung durchführt.

Hier wäre vielleicht ein Hinweis auf die URL http://storaged.org/doc/udisks2-api/latest/mount_options.html (seit Kernel 6.xx) hilfreich. Dort findet man die für udisks2 gültigen Voreinstellungen für alle Treiber und auch die jeweils zulässigen individuellen Einstellungen.

Im hiesigen Artikel wird auf den Artikel UDisks verwiesen, in den derartiges gehört und auch schon steht und diskutiert wird.

Wird das Einbinden hingegen durch einen Eintrag in fstab mit noauto vorbereitet, so ist (zumindest bei NTFS3) immer Root und nicht der Besitzer des Einbindungsprozesses scheinbarer Eigentümer, wenn dort für uid und gid nichts anderes eingetragen ist.

Das entspricht nicht meinen Erfahrungen. Bei mir wird immer der Besitzer des einbindenden Prozesses zum Besitzer des eingebundenen Dateisystems, egal ob ich dafür mount oder udisksctl oder Automatiken des Desktops oder Bedienelemente des Desktops verwende. Und die Optionen uid und gid muss ich bei ntfs3 gar nicht verwenden, um praxistaugliche Ergebnisse zu erhalten – im Gegensatz zu FAT und exFAT.

Unter Winwows ist diese Betriebsart immer aktiviert, unter Linux ist sie standardmäßig ausgeschaltet. (betr. windows_names)

Dies stimmt für mount und für fstab-Einträge. Bei udisks2 und damit auch beim Einbinden per GUI ist sie jedoch standardmäßig eingeschaltet.

An dieser Stelle geht es um eine spezielle Eigenschaft des Dateisystems NTFS, die im Windows-Kernel und im Linux-Kernel unterschiedlich behandelt wird. Das hat mit mount, fstab, udisks2 oder GUI gar nichts zu tun.

Einige Zeilen weiter steht, dass man im Linux-Kernel das Verhalten wie bei Windows einschalten kann, eben über die Mount-Option windows_names. Und da steht auch, dass mount das selbst nicht macht, wohl aber udisks2 (und damit auch jede GUI, welche UDisks benutzt.

Mit der Angabe ntfs selektiert man hier faktisch ntfs-3g. (steht bei UDisks bzw. udisksctl).

Im Gegensatz zu mount bzw. fstab wird bei UDisks der Treiber NTFS3 und nicht NTFS-3G selektiert, wenn man ntfs angibt.

Auch hier sind meine Erfahrungen nicht so einfach und klar, wie Du Deine darstellst. Tatsächlich erscheint mir das Verhalten eher erratisch zufällig, was es natürlich nicht wirklich ist. Es hängt aber von vielen Umständen und Einstellungen ab, die sich bei verschiedenen Versionen auch unterschiedlich auswirken. Deshalb auch die dringende Empfehlung im Artikel, sich gar nicht auf irgendwelche „Systemstandards“ zu verlassen, sondern selber einzustellen, was man haben will.

Das ist zwar inhaltlich richtig, hat aber gar nicht mit NTFS oder anderen Windows-Dateisystemen zu tun, sondern beruht auf der grundsätzlichen Rolle von fstab beim Systemstart.

Das weiß ich schon. Nur tritt bei NTFS3 das Problem eben gehäuft auf, weil bei NTFS bei jedem "unsauberen" shutdown das Dirty-Bit gesetzt wird und NTFS3 dann die Partition nicht mehr einbindet. Bei NTFS-3G (!) und bei anderen Dateisystemen ist das nicht so.

…wird 4 GiB als unpraktikabel klein empfinden.

Da bin ich wirklich "von gestern"! Das muss ich zugeben. Vielleicht sogar schon von vorgestern…

Im hiesigen Artikel wird auf den Artikel UDisks verwiesen, in den derartiges gehört und auch schon steht und diskutiert wird.

Ok. War mir so nicht bewusst, sorry.

Das entspricht nicht meinen Erfahrungen. Bei mir wird immer der Besitzer des einbindenden Prozesses zum Besitzer des eingebundenen Dateisystems, egal ob ich dafür mount oder udisksctl oder Automatiken des Desktops oder Bedienelemente des Desktops verwende

Das entspricht auch meiner Erfahrung, solange das Einbinden nicht mittels fstab-Eintrag mit noauto vorbereitet ist. Ich will dies nochmal überprüfen. Vielleicht habe ich mich auch getäuscht.

An dieser Stelle geht es um eine spezielle Eigenschaft des Dateisystems NTFS, die im Windows-Kernel und im Linux-Kernel unterschiedlich behandelt wird.

Hier handelt es sich um ein Missverständnis. Ich meine hier, ob die Option "windows_names" standardmäßig gesetzt ist oder nicht. Zugegeben, das Wort "Betriebsart" ist von mir dafür nicht glücklich gewählt.

Im Gegensatz zu mount bzw. fstab wird bei UDisks der Treiber NTFS3 und nicht NTFS-3G selektiert, wenn man ntfs angibt.

So steht es auch in der o.g. URL http://storaged.org/doc/udisks2-api/latest/mount_options.html. Möglicherweise gilt dies aber erst ab Kernel 6.xx, was deine andersartigen Erfahrungen erklären könnte.

EDIT:

Auch wenn es wie "Griffelspitzerei" aussieht, möchte ich wegen windows_names doch nochmal nachhaken:

NTFS kennt aber auch eine optionale Betriebsart, in der einige von Windows unerwünschte Zeichen in Dateinamen unzulässig sind. Unter Windows ist diese Betriebsart immer aktiviert, unter Linux ist sie standardmäßig ausgeschaltet.

Die zwei verschiedenen Betriebsarten des Dateisystems NTFS in Windows und "standardmäßig" in Linux leuchten mir so, wie im Artikel beschrieben, ein. Aber ich bin immer davon ausgegangen, dass in Linux immer die gleiche Betriebsart mit dem größeren Fundus zulässiger Zeichen beibehalten wird, egal ob die Mount-Option windows_names gesetzt ist oder nicht. Denn Dateinamen mit unter Windows "unzulässigen" Zeichen werden immer erkannt und verwaltet, die Option windows_names verhindert nur, dass solche Dateinamen neu vergeben werden. Also ganz anders als unter Windows.

Ich stelle mir deshalb windows_names nur wie ein Filter bei der Vergabe von Dateinamen und nicht wie ein Umschalten der Betriebsart des Dateisystems vor. Sehe ich das falsch?

Dieser Unterschied der Sichtweise ist aber wahrscheinlich in der Praxis unwichtig.

Max-Ulrich_Farber schrieb:

Das ist zwar inhaltlich richtig, hat aber gar nicht mit NTFS oder anderen Windows-Dateisystemen zu tun, sondern beruht auf der grundsätzlichen Rolle von fstab beim Systemstart.

Das weiß ich schon. Nur tritt bei NTFS3 das Problem eben gehäuft auf, weil bei NTFS bei jedem "unsauberen" shutdown das Dirty-Bit gesetzt wird und NTFS3 dann die Partition nicht mehr einbindet. Bei NTFS-3G (!) und bei anderen Dateisystemen ist das nicht so.

Bzgl. des Dirty-Bits ist ntfs3 in der Praxis zickiger als ntfs-3g, aber das beruht vielleicht auf einem Trugschluss, da ntfs3 wohl die automatische Rückfalloption auf ro nach Fehler fehlt und ntfs-3g so etwas hat.

[…] Ich meine hier, ob die Option "windows_names" standardmäßig gesetzt ist oder nicht.

Hier gilt ein glasklares „manchmal“!

Im Linux-Kernel, d.h. im Modul ntfs3 inst windows_names nicht eingeschaltet, aber UDisks setzt sie über seine Standardoptionen manchmal, d.h. ab einer bestimmten Version. Das führt zu dem unschönen Ergebnis, dass abhängig von der Ubuntu-Version und vom Werkzeug (mount oder udisksctl) manchmal die Option gesetzt ist und manchmal nicht. Verschärfend kommt noch dazu, dass der Linux-Kernel die Option erst ab einer bestimmten Version überhaupt kennt. (Die Optionen stehen im Wiki.)

[…]

Im Gegensatz zu mount bzw. fstab wird bei UDisks der Treiber NTFS3 und nicht NTFS-3G selektiert, wenn man ntfs angibt.

So steht es auch in der o.g. URL http://storaged.org/doc/udisks2-api/latest/mount_options.html. Möglicherweise gilt dies aber erst ab Kernel 6.xx, was deine andersartigen Erfahrungen erklären könnte.

Das hat weniger mit der Version des Kernels und mehr mit der Version von UDisks zu tun. Früher hatte UDisks gar nicht die Möglichkeit, alternative Treiber zu präferieren.

Das alles führt zu der Empfehlung im Wiki, den Modul ntfs3 erst ab Ubuntu 22.04 HWE mit einem Kernel ab Version 6.4 zu verwenden; 22.04 LTS ist noch zu wackelig. Aber auch bei diesen hinreichend neuen System bleibt der Unterschied bzgl. windows_names zwischen mount und udisksctl.

Bzgl. des Dirty-Bits ist ntfs3 in der Praxis zickiger als ntfs-3g, aber das beruht vielleicht auf einem Trugschluss, da ntfs3 wohl die automatische Rückfalloption auf ro nach Fehler fehlt und ntfs-3g so etwas hat.

Mit der Rückfalloption hat das AFAIK normalerweise nichts zu tun. Bei NTS-3G ist standardmäßig die Option recover gesetzt, sodass das Dirty-Bit ignoriert und sogar beim Einbinden gelöscht wird – ein bequemes, aber nicht gerade ungefährliches Verhalten! Denn, wie bei Windows, automatisch repariert wird die Partition dabei trotzdem nicht. Der Rückfall auf ro findet AFAIK nur bei norecover statt, verhindert aber auch dann den Abbruch des Boot-Prozesses.

Weil es bei NTFS3 keinen Rückfall auf ro gibt, bleibt da nur die Möglichkeit der Option nofail in der fstab.

So steht es auch in der o.g. URL http://storaged.org/doc/udisks2-api/latest/mount_options.html. Möglicherweise gilt dies aber erst ab Kernel 6.xx, was deine andersartigen Erfahrungen erklären könnte.

Ich habe inzwischen nochmal im Artikel UDisks2 nachgelesen. Dort finde ich diese URL nicht angegeben. Statt dessen steht dort im Abschnitt Interne Vorgaben:

Diese Vorgaben auf Ebene I sind fest in den Programmcode eingearbeitet und können selbst nicht verändert werden. Ihre Werte entsprechen denjenigen, als wäre auf Ebene II die unten angegebene Beispieldatei wirksam.

Die obige URL ist eine Liste der tatsächlichen aktuell fest in den Programmcode eingearbeiteten Vorgaben der Ebene I. Diese stimmen bei mir nicht mit denen der in Ebene II angegebenen Beispieldatei überein. Deshalb erscheint mir die Angabe der URL schon sinnvoll bzw. nötig, wobei wohl der Artikel UDisks2 schon der richtige Ort wäre.

… Diese stimmen bei mir nicht mit denen der in Ebene II angegebenen Beispieldatei überein.

Hierfür habe ich auch eine Erklärung. Meine Beispieldatei ist offenbar veraltet; ich habe bei XUbuntu 22.04 vom beim Upgrade von 20.04 übernommenen LTS-Kernel 5.xx auf den HWE-Kernel 6.xx umgestellt, und dabei wurde die Beispieldatei natürlich nicht angepasst. Im "Normalfall" dürften wohl keine Unterschiede bestehen.

Max-Ulrich_Farber schrieb:

[…]

So steht es auch in der o.g. URL http://storaged.org/doc/udisks2-api/latest/mount_options.html. Möglicherweise gilt dies aber erst ab Kernel 6.xx, was deine andersartigen Erfahrungen erklären könnte.

Ich habe inzwischen nochmal im Artikel UDisks2 nachgelesen. Dort finde ich diese URL nicht angegeben.

Aber unter Links eben einen Link auf das UDisks Reference Manual, welches alle Versionen von UDisks berücksichtigt und eben auch auf Deine URL verzweigt.

Statt dessen steht dort im Abschnitt Interne Vorgaben:

Diese Vorgaben auf Ebene I sind fest in den Programmcode eingearbeitet und können selbst nicht verändert werden. Ihre Werte entsprechen denjenigen, als wäre auf Ebene II die unten angegebene Beispieldatei wirksam.

Die Beispieldatei im Wiki stammt aus dem UDisks Reference Manual und ist leicht versionsabhängig, was im Text auch angesprochen wird.

Die obige URL ist eine Liste der tatsächlichen aktuell fest in den Programmcode eingearbeiteten Vorgaben der Ebene I. Diese stimmen bei mir nicht mit denen der in Ebene II angegebenen Beispieldatei überein. Deshalb erscheint mir die Angabe der URL schon sinnvoll bzw. nötig, wobei wohl der Artikel UDisks2 schon der richtige Ort wäre.

In unserem Wiki ist auch die URL file:///usr/share/gtk-doc/html/udisks2/index.html angegeben, welche die für Deinen Rechner konkret geltende Dokumentation liefert, sofern Du das Dokumentationspaket für UDisks installiert hast.

Ich prüfe aber nochmal, ob das Thema Dokumentation verbessert werden kann.

Hallo zusammen,

in Windows-Partitionen unter Linux (Abschnitt „Formatierung-berpruefung-und-Pflege“) könnten m.E. noch zwei Absätze eingefügt werden:

• als (dann) viertletzter, mit dem Text: „Für die Wartung vom FAT-Dateisystemen benötigt man das Paket dosfstools, siehe Artikel dosfstools.“

• als letzter, mit dem Text: „Siehe diesbezüglich auch den nächsten Abschnitt.“

linux_joy schrieb:

[…] könnten m.E. noch zwei Absätze eingefügt werden:

• als (dann) viertletzter, mit dem Text: „Für die Wartung vom FAT-Dateisystemen benötigt man das Paket dosfstools, siehe Artikel dosfstools.“

Das steht doch bereits als Einleitung in diesem Abschnitt! Ok, den anderen Artikel könnte man noch verlinken.

• als letzter, mit dem Text: „Siehe diesbezüglich auch den nächsten Abschnitt.“

Das ist doch Unsinn, am Ende eines Abschnitts den Leser aufzufordern, mit dem nächsten Abschnitt weiter zu lesen. Zumal die beiden Abschnitte unterschiedliche Themen behandeln und genau aus diesem Grund auch jeweils eigene Abschnitte sind.

Hallo kB, Du schriebst:

linux_joy schrieb:

[…] könnten m.E. noch zwei Absätze eingefügt werden:

• als (dann) viertletzter, mit dem Text: „Für die Wartung vom FAT-Dateisystemen benötigt man das Paket dosfstools, siehe Artikel dosfstools.“

Das steht doch bereits als Einleitung in diesem Abschnitt! Ok, den anderen Artikel könnte man noch verlinken.

Pardon, ich hatte den Überblick verloren. Ich habe jetzt mal in der Einleitung den 1. Satz: verändert: „...benötigt man das Paket dosfstools, welches bei Ubuntu...“ → „...benötigt man das Paket dosfstools (siehe Artikel dosfstools), welches bei Ubuntu...“. Leider ist mir beim Bearbeitungs-Kommentar ein kleiner Fauxpax unterlaufen: „Paket dosfstools“ muss in der Änderung natürlich heißen: „Paket dosfstools“! Leider kann ich den Kommentar nicht separat bearbeiten... Da hat also einer Inyoka überschätzt, und ein anderer ist dadurch durcheinandergekommen 😉 ... Hah, im Forum funzt gleichzeitige Fettung/Verlinkung... ☹

• als letzter, mit dem Text: „Siehe diesbezüglich auch den nächsten Abschnitt.“

Das ist doch Unsinn, am Ende eines Abschnitts den Leser aufzufordern, mit dem nächsten Abschnitt weiter zu lesen. Zumal die beiden Abschnitte unterschiedliche Themen behandeln und genau aus diesem Grund auch jeweils eigene Abschnitte sind.

Der nächste Abschnitt „Auswahl des Dateisystemtyps“ hat als letzten Satz „Defekte FAT und exFAT Dateisysteme können auch unter Linux repariert werden, bei NTFS sollte man hierfür ein Windows bereithalten.“. Dieser Satz ist dort zwar grundsätzlich angebracht, könnte aber ebensogut in „Formatierung, Überprüfung und Pflege“ stehen.