ubuntuusers.de

😳 - gemacht.

Max-Ulrich_Farber schrieb:

[…] Ich bitte um (konstruktive…) Kritik, Ergänzungen, Verbesserung von Fehlern und Schönheitsfehlern.

Ich bin erst zur Hälfte durch mit dem Korrekturlesen und habe einige Typos bekämpft, Links hinzugefügt und repariert sowie einige Details ergänzt.

Den Abschnitt Sonderzeichen habe ich umbenannt in Dateinamen und heftiger überarbeitet.

Zwei Formulierungen sind mir aufgefallen, weil unklar oder sogar falsch:

Zudem wurde auch die Utility-Sammlung exfat-utils von Samsung überarbeitet und an den Kernel-Treiber angepasst. Sie kann, nach wie vor über FUSE laufend, als exfatprogs aus den Paketquellen installiert werden.

Erscheint mir falsch. Was haben Dienstprogramme mit FUSE zu tun?

Außerdem ist bei exFAT die Länge von Dateinamen für den ganzen Pfad (!) auf 255 Byte beschränkt. In Linux-Dateisystemen gilt diese Beschränkung hingegen nur für den lokalen Dateinamen, der Pfad darf dort bis zu 4096 Zeichen lang sein. Zu beachten ist, dass Sonderzeichen auch mehrere Byte belegen können.

Erscheint mir auch falsch. Woher stammt diese Aussage?

Ich mache demnächst weiter mit meiner Durchsicht ab Aschnitt „Simulierte Dateirechte“.

kB schrieb:

[...]

Zudem wurde auch die Utility-Sammlung exfat-utils von Samsung überarbeitet und an den Kernel-Treiber angepasst. Sie kann, nach wie vor über FUSE laufend, als exfatprogs aus den Paketquellen installiert werden.

Erscheint mir falsch. Was haben Dienstprogramme mit FUSE zu tun? [...]

Naja, es sind Userspace-Anwendungen, die darum auch durch nicht-privilegierte Benutzer ausgeführt werden können. Den Samsung-Teil finde ich aber merkwürdig. Davon habe ich keine Evidenz auf der Projektseite finden können.

Danke für die Durchsicht!

@ Samsung:

… exfatprogs is a codebase created by Samsung while exfat-utils was a completely independend implementation by another developer

… New in Debian is the exfatprogs package written by the Samsung engineers. (Debian)

…The tools included in this package are the exfatprogs maintained by Samsung engineers, who provided Linux exFAT support. A similar but independent implementation of these tools, written by the author of the exfat-fuse implementation, are available in the exfat-utils package.(Ubuntu,Jammy)

@Pfadlänge:

Siehe Dateisystem (Abschnitt „Pfadlaenge“). Ich habe versucht, in Ubuntu mit dem Dateimanager auf einer externen exFAT-Partition einen Dateipfad über 255 Zeichen Länge zu erzeugen. Wurde abgelehnt: "Dateinamen ungültig". Dann habe ich versucht, eine Datei mit langem Namen auf einen bereits langen Pfad zu kopieren. Ging in exFAT auch nicht, in ext4 schon. Es kann sein, dass diese Beschränkung der Pfadlänge nicht am Dateisystem liegt, sondern am Treiber. Doch der Effekt ist der gleiche.

Habe dazu auch folgenden Diskussionsbeitrag gefunden:

Ja, ich glaube wir verstehen uns. Die Regel ist eigentlich ziemlich einfach. Zum Erreichen einer Datei darf der dafür nötige Pfad - egal ob absolut oder relativ - nicht länger als 4095 Zeichen lang sein. Falls die Datei aber "weiter entfernt" liegt, so muss man sich erstmal - nötigenfalls in mehreren Schritten - per "cd" in die Richtung hangeln...

Stimmt das so?? – ist hier aber etwas off topic.

@ Werkzeugprogramme und FUSE:

Die Werkzeugprogramme von ntfsprogs hantieren doch ein Dateisystem, das dazu nicht eingehängt sein muss. Ich denke, das kann schon über FUSE geschehen. Aber man sollte da vielleicht besser sagen "… laufen im Userspace", das wäre klarer.

@ Dateinamen

Windows unterscheidet bei Datei- und Ordnernamen nicht zwischen Groß- und Kleinbuchstaben, die Windows-Dateisysteme aber sehr wohl. Man kann in einem exFAT-Dateisystem durchaus wie auf einem nativen Linux-Dateisystem Groß- und Kleinbuchstaben verwenden, wenn man eine Besonderheit beachtet:

So kann man das nicht sagen. Groß- und Kleinbuchstaben werden vom Dateisystem bewahrt, aber nicht unterschieden. Die Unterscheidung macht der Dateisystem-Treiber, oder er macht sie eben nicht. Bei NTFS-3G kann man dies wahlweise einstellen, die Linux-Treiber von exFAT machen keinen Unterschied.

Dies ist bei jedem exFAT-Dateisystem eine normale Restriktion und kein Anzeichen für einen Schaden der Hardware. Von diesem Effekt sind alle Zeichen betroffen, welche im Dateisystem in einer besonderen Tabelle gespeichert sind. Diese Tabelle kann grundsätzlich zwar auch für jedes Dateisystem individuell gepflegt werden, allerdings fehlt bei Linux dafür ein geeignetes Dienstprogramm. Automatisch und unveränderlich sind aber immer die ASCII-Zeichen a-z/A-Z dieser Einschränkung unterworfen.

Das ist sicher richtig, aber imho unnötig kompliziert. Es genügt wohl "Dies würde bedeuten, die Datei wird auf sich selbst verschoben, und das geht nicht" Für welche andere Zeichen das auch der Fall wäre, kann ausprobieren, wer will!

Die in Linux-Dateisystemen erforderlichen Dateinamen (Hardlinks) . und .. sind in exFAT-Dateisystemen verboten; beim Auflisten eines Ordners werden zwar solche Einträge angezeigt, denen aber im Dateisystem keine Dateien entsprechen.

Das verstehe ich nicht. Die Zeichen . und .. funktionieren im exFAT-Dateisystem genau so, (habe ich gerade nochmal probiert) und für den Rest reicht mir die Information "Hard- und Softlinks funktionieren nicht". Mache Dir und uns das Leben doch bitte nicht unnötig schwer!

Ich meine, wir müssen immer die Zielgruppe im Auge behalten. Und das sind nicht Entwickler und IT-Spezialisten, sondern "Ubuntu Users", d.h. Anwender.

@kB:

Ich hatte nie die geringsten Zweifel, dass du über ein viel größeres Hintergrund-Wissen verfügst als ich. Deshalb bin ich dafür dankbar, dass du meine Formulierungen durchsiehst und mich auf eventuelle Unkorrektheiten hinweist. Das ist gut so.

Doch es war immer mein Anliegen, so einfach wie möglich zu schreiben und dabei auf Informationen zu verzichten, die für den einfachen Benutzer in der Praxis keine Rolle spielen. Für weiter gehende Informationen gibt es ja die Experten-Box, von der man aber auch lieber sparsam Gebrauch machen sollte.

Ich denke, die Leser, die du mit deinen zweifellos sehr interessanten Ausführungen ansprichst, sind wohl eher clevere Leute, die sicher in der Lage sind, sich in den Original-Texten der Entwickler zu informieren.

Bitte habe deshalb Verständnis für meine Bitte, einfach zu bleiben!

Beste Grüße und auf weitere gute Zusammenarbeit!

Max-Ulrich_Farber schrieb:

[…] @Pfadlänge: […]

Bei mir (Ausgabe gekürzt):

$ ls -ARl
…
./123456789012345678901234567890123456789012345678901234567890/abcdefghijABCDEFGHIJabcdefghijABCDEFGHIJabcdefghijABCDEFGHIJabcdefghijABCDEFGHIJ/1234567890abcdefghij1234567890abcdefghij1234567890abcdefghij1234567890abcdefghij/ABCDEFGHIJ1234567890ABCDEFGHIJ1234567890ABCDEFGHIJ1234567890ABCDEFGHIJ1234567890:
insgesamt 0
-rwxrwxrwx 1 root root 0 Feb  5 10:15 ''$'\357\277\277'
-rwxrwxrwx 1 root root 0 Sep 17  2021 'Langer Dateiname mit großen und kleinen Buchstaben und Sonderzeichen wie äöüß ÄÖÜ'
$

Das ist eine Hierarchie von 4 Ordnern mit jeweils 80 Zeichen im Dateinamen und darin 2 Dateien mit langen Namen, also deutlich mehr als 300 Zeichen im Pfad.

Die zulässige Länge des Pfades hat nichts mit dem Dateisystem zu tun, da ein Dateisystem gar keine Pfade kennt. „Pfad“ ist ein Element der Benutzeroberfläche, also des Betriebssystems und eventuell (aber eher unwahrscheinlich) des Dateisystem-Treibers. Windows hatte früher und hat vielleicht noch immer eine Beschränkung des Pfades auf 260 Zeichen (oder waren das Byte?) unabhängig vom Dateisystem und Linux hat meines Wissens schon immer eine Beschränkung auf 4095 Byte unabhängig vom Dateisystem.

@ Werkzeugprogramme und FUSE:

Die Werkzeugprogramme von ntfsprogs hantieren doch ein Dateisystem, das dazu nicht eingehängt sein muss. Ich denke, das kann schon über FUSE geschehen. Aber man sollte da vielleicht besser sagen "… laufen im Userspace", das wäre klarer.

Dienstprogramme laufen immer im Userspace (Man kann es trotzdem im Artikel erwähnen.) und FUSE ist nur für das Einhängen zuständig. Operationen wie Formatieren, Prüfen und Reparieren bearbeiten die Datei (!), welche das Dateisystem enthält, am Dateisystem-Treiber vorbei. Man macht das besser im nicht eingehängten Zustand, um zu verhindern, dass gleichzeitig zwei Prozesse unkoordiniert in die Datei schreiben, weil das Schäden verursacht. Das gilt allgemein und hat mit exFAT speziell nichts zu tun.

@ Dateinamen

Windows unterscheidet bei Datei- und Ordnernamen nicht zwischen Groß- und Kleinbuchstaben, die Windows-Dateisysteme aber sehr wohl. Man kann in einem exFAT-Dateisystem durchaus wie auf einem nativen Linux-Dateisystem Groß- und Kleinbuchstaben verwenden, wenn man eine Besonderheit beachtet:

So kann man das nicht sagen. Groß- und Kleinbuchstaben werden vom Dateisystem bewahrt, aber nicht unterschieden.

Jedenfalls kann man in einem exFAT-Dateisystem in Dateinamen Groß- und Kleinbuchstaben (auch gemischt) und jedes Unicode-Zeichen bis auf die genannten Ausnahmen verwenden und so ein Dateiname wird auch dauerhaft, selbst nach dem Aushängen, im Dateisystem gespeichert.

Die Unterscheidung macht der Dateisystem-Treiber, oder er macht sie eben nicht.

Nein, nicht bei exFAT. Ein spezifikationsgerechtes exFAT-Dateisystem muss die Dateinamen a und A als Synonyme betrachten. Man kann sowohl den einen oder den anderen speichern, aber nicht beide gleichzeitig. Dieser Up-Case-Mechanismus für Windows-konformes Benehmen muss implementiert sein und darf daher auch nicht abschaltbar sein.

Bei NTFS-3G kann man dies wahlweise einstellen, die Linux-Treiber von exFAT machen keinen Unterschied.

Bei NTFS ist die Frage der Gruß- und Kleinschreibung anders realisiert als bei exFAT. In einem NTFS-Dateisystem kann man die Dateinamen a und A gleichzeitig verwenden und speichern, erst Windows identifiziert die beiden als Synonyme und gerät in Panik, wenn ihm sein NTFS-Dateisystem tatsächlich so etwas liefert. Deshalb darf es (und gibt es in der Regel) bei NTFS einen zuschaltbaren Kompatibilitätsmodus für Windows geben, in dem sich das Dateisystem weigert, gleichzeitig Dateinamen zu verwenden, die Windows als Synonyme behandelt.

Dies ist bei jedem exFAT-Dateisystem eine normale Restriktion und kein Anzeichen für einen Schaden der Hardware. Von diesem Effekt sind alle Zeichen betroffen, welche im Dateisystem in einer besonderen Tabelle gespeichert sind. Diese Tabelle kann grundsätzlich zwar auch für jedes Dateisystem individuell gepflegt werden, allerdings fehlt bei Linux dafür ein geeignetes Dienstprogramm. Automatisch und unveränderlich sind aber immer die ASCII-Zeichen a-z/A-Z dieser Einschränkung unterworfen.

Das ist sicher richtig, aber imho unnötig kompliziert. Es genügt wohl "Dies würde bedeuten, die Datei wird auf sich selbst verschoben, und das geht nicht" Für welche andere Zeichen das auch der Fall wäre, kann ausprobieren, wer will!

Mag sein, dass Microsoft es per Spezifikation unnötig kompliziert gemacht hat, aber in diesem Textteil stehen nur praxisrelevante Eigenschaften, die aus meiner Sicht unbedingt in diesen Artikel gehören:

1. Die Meldung eines „Ein-Ausgabe-Fehlers“ wird üblicherweise als Hardware-Schaden interpretiert; in diesem Fall ist es aber nur ein harmloser Bedienfehler.

2. Der Bedienfehler entsteht durch den eingebauten Up-Case-Mechanismus. Das ist eine Besonderheit bei exFAT.

3. Dieser Mechanismus ist individuell auf Zeichenebene konfigurierbar, allerdings unter Linux nicht. Unterschiedliche exFAT-Dateisysteme können sich daher unterschiedlich verhalten.

Zur einfachen Formulierung dieser Eigenschaften können wir uns noch anstrengen.

Die in Linux-Dateisystemen erforderlichen Dateinamen (Hardlinks) . und .. sind in exFAT-Dateisystemen verboten; beim Auflisten eines Ordners werden zwar solche Einträge angezeigt, denen aber im Dateisystem keine Dateien entsprechen.

Das verstehe ich nicht. […]

Es ist eine Auflösung eines offensichtlichen Widerspruchs:

1. Hardlinks gibt es nicht bei exFAT.

2. Es werden die Ordner . und .. angezeigt. Das sind Hardlinks.

Auflösung: Es gibt diese Dateien tatsächlich nicht, sie werden aber simuliert, d.h. man kann mit ihnen wie gewohnt umgehen.

Die volle Wahrheit für bereits Wahnsinnige: Die beiden Dateinamen . und .. sind in exFAT verboten, damit das übliche Verhalten dieser Hardlinks simuliert werden kann und die Simulation nicht durch tatsächlich vorhandene Dateien gestört werden kann.

Mache Dir und uns das Leben doch bitte nicht unnötig schwer!

Das liegt mir ferne. Mein Ansatz ist:

• Ich mache mir das Laben schwer, damit die Leser des Artikels es einfacher haben.

Dazu gehört für mich, dass beim normalen Umgang mit diesem Dateisystem unter Linux möglicherweise auftretende Probleme angesprochen werden. Wenn hinter solchen Problemen komplizierte technische Entscheidungen stehen, soll der Artikel zumindest so viele Anhaltspunkte/Suchbegriffe liefern, dass der interessierte Leser selbst weiter suchen kann.

Es ist eine Auflösung eines offensichtlichen Widerspruchs: Hardlinks gibt es nicht bei exFAT. Es werden die Ordner . und .. angezeigt. Das sind Hardlinks.

Das hatte ich schon verstanden. Was ich nicht verstehe ist, wieso . und .. trotzdem funktionieren. Und deshalb wollte ich diesen Widerspruch gar nicht erwähnen. Denn für den "gewöhnlichen User" ist er irrelevant, und die "Experten" können sich ’wo anderes schlau machen…

Doch jetzt verstehe ich erst, was du meinst: . und .. sind für den Anwender verboten, d.h. als Dateinamen nicht erlaubt, weil sie anderweitig schon verwendet werden, und das, obwohl es gar keine Hardlinks gibt. Aber das ist ja schon recht kompliziert. Und wer kommt denn auf die absurde Idee, . oder .. als Dateinamen zu verwenden? Da man dies ja auch in anderen Dateisystemen nicht tut – eben nur mit anderer Begründung – kann man dies wohl getrost weglassen (?) Wenn aber doch nötig, dann vielleicht Experten-Box?

Nein, nicht bei exFAT. Ein spezifikationsgerechtes exFAT-Dateisystem muss die Dateinamen a und A als Synonyme betrachten.

Das wusste ich noch nicht. Habe wieder ’was dazugelernt. – Aber muss der Anwender das wissen?

@Pfadlänge: Ich erstehe das auch nicht. Das mit max. 255 Zeichen (oder Byte?) in e3xFAT habe ich gelesen und gleich ausprobiert, über den Dateimanager. Bei mir ging es in exFAT nicht, in ext4 aber wohl. Was dann der Grund für den Unterschied gewesen sein könnte, weiß ich nicht; Details des Versuchs (Sonderzeichen?) habe ich nicht notiert.

Dienstprogramme laufen immer im Userspace (Man kann es trotzdem im Artikel erwähnen.) und FUSE ist nur für das Einhängen zuständig.

Dann lasse ich den Hinweis besser ganz weg. Gemeint war: Zum Mounten mittels Kernel-Treiber benötigt man Root-Rechte, für die Dienstprogramme dagegen nicht. Ist eigentlich selbstverständlich, weil auch sonst so üblich.

Ich mache mir das Laben schwer, damit die Leser des Artikels es einfacher haben.

Das ist ja das Ziel von uns allen. Nur haben wir vielleicht bei "Leser" nicht immer genau die gleiche Zielgruppe im Auge. Aber deshalb diskutieren wir ja! 👍

Off topic:

An meinem 80. Geburtstag im Jahr 2021 hatte ich mir vorgenommen, jetzt aus Altersgründen mit der Wiki-Arbeit definitiv aufzuhören. Und nun stecke ich schon wieder ganz schön drin! – Man tut halt nicht immer was man will…

Ein ganz anderes Problem: Weil exFAT vor allem für USB-Speichermedien verwendet wird, sollte man unbedingt zu den Mount-Optionen flush und sync noch etwas sagen. Doch leider blicke ich da selbst noch nicht richtig durch:

• Wird flush in exFAT überhaupt unterstützt und, wenn ja, gleichermaßen von beiden Treibern?

• mit sync kann man unter FAT32 Flash-Speichermedien schnell kaputt machen, weil FAT und FAT-Kopie evtl. in kürzester Zeit vielmals überschrieben werden. Mit flush ist das wohl ein bisschen besser, aber dafür auch weniger sicher bei "unordentlichem" unplug.

• Wie sieht es mit sync unter exFAT aus? Ich vermute, entsprechend, nur dass es keine FAT-Kopie gibt. Aber sicher weiß ich da gar nichts…

• Die gelegentlich zu findende Angabe, bei VFAT sei sync für USB-Speicher per default aktiviert, stimmt mit Sicherheit nicht. Wenigstens in Linux.

Ein Hinweis, dass es wegen des fehlenden Journaling ganz besonders wichtig ist, Schreibvorgänge auf das Medium (!) nie zu unterbrechen, wäre sicher kein Fehler. Aber dafür sollte man eben über die Risiken von sync und flush für die Hardware Bescheid wissen.

kB, kannst du mir da helfen?

EDIT:

Und gleich noch ein Problem:

Bei exFAT finde ich in mehreren Posts den Hinweis, dass dann, wenn beim Aushängen "fertig" angezeigt wird, oftmals noch nicht alle Daten wirklich auf den Datenträger geschrieben sind. Alle diese Angaben stammen aus der Zeit, als es für exFAT nur den FUSE-Treiber gab. Ich kann mir nur vorstellen, dass es sich um eine FUSE-Pufferung handelt, die nicht angezeigt wird. Wenn dies nach wie vor beobachtet wird, ist eine Treiber-spezifische Warnung unbedingt angebracht.

Eigenartig: Bei NTFS-3G bin ich diesem Problem nicht begegnet. Vielleicht deshalb, weil NTFS für entfernbare Datenträger seltener verwendet wird (??). Oder vielleicht verwendet NTFS-3G andere FUSE-Parameter (siehe man fuse). Trotzdem seltsam.

Ich habe jetzt nochmal gründlich in Internet-Blogs gelesen:

Entwarnung beim zweiten "Problem": offenbar handelt es sich wieder um das Übliche: Beim unmount nicht lange genug gewartet bzw. bei DualBoot in Windows automatisch wieder eingeschaltetes FastBoot. Dafür ist die Warnung in ntfs-3g bereits vorhanden und kann entsprechend übernommen bzw. verlinkt werden.

Die vorschnelle Abnützung von Flash-Speichern mit sync bzw. flush leuchtet ein; etwas Spezielles für exFAT konnte ich nicht finden. Ich denke, ein gewöhnlicher Hinweis ist vielleicht angebracht, aber keine Warnung. Ein Hinweis steht ja auch in man mount unabhängig vom Dateisystem:

All I/O to the filesystem should be done synchronously. In the case of media with a limited number of write cycles (e.g. some flash drives), sync may cause life-cycle shortening.

Ich bringe den Hinweis noch im Artikel mount ein, das muss genügen.

Ab der Version 1.4.0 enthält exfat-utils jedoch das Programm exfatattrib. Diese Version ist über die offiziellen Paketquellen von Ubuntu nicht verfügbar; man muss es von der Projektseite als Quellcode herunterladen und selbst compilieren.

Ist diese Experten-Info noch nötig? Die Version 1.1.3-1 von exfatprogs in den Paketquellen ist längst veraltet und enthält z.B. das Tool exfat2img noch gar nicht. Die aktuelle Version 1.2.2-1 habe ich noch nicht installiert. Macht eventuell exfat2img das Gewünschte auch?

Weil sich exfat-utils und exfatprogs nicht mögen, sollte man sich entscheiden. In den Paketquellen ist exfatprogs.

Max-Ulrich_Farber schrieb:

[…] Die vorschnelle Abnützung von Flash-Speichern mit sync bzw. flush leuchtet ein; etwas Spezielles für exFAT konnte ich nicht finden.

Flash-Speicher altern bei jedem Schreibvorgang, das hat mit dem Dateisystem erst einmal gar nichts zu tun. Allerdings kann auf der Ebene des Dateisystems durch Design (nicht unsere Baustelle) oder optimierte Betriebsbedingungen (ggf. über Optionen) Schreibvorgänge minimieren, was speziell bei exFAT beispielsweise bzgl. des Dirty-Bits im Bootsektor geschehen ist. Die generell zu empfehlende Strategie ist daher, beim Einbinden für Optionen, welche Einfluss auf Schreibvorgänge haben, möglichst die Standardwerte des Treibers zu verwenden und diese nur begründet und mit Sachverstand zu ändern. Dazu gehören u.a. die Optionen sync/async, flush, relatime.

Öfter zu Schreiben, nur um beim Arbeitsende den USB-Stick hektisch herausreißen zu können, ist Unfug.

Ab der Version 1.4.0 enthält exfat-utils jedoch das Programm exfatattrib. Diese Version ist über die offiziellen Paketquellen von Ubuntu nicht verfügbar; man muss es von der Projektseite als Quellcode herunterladen und selbst compilieren.

Ist diese Experten-Info noch nötig? Die Version 1.1.3-1 von exfatprogs in den Paketquellen ist längst veraltet und enthält z.B. das Tool exfat2img noch gar nicht. Die aktuelle Version 1.2.2-1 habe ich noch nicht installiert. Macht eventuell exfat2img das Gewünschte auch?

Ich habe diesen Hinweis angebracht, ja ich die Situation bei exFAT unter Linux bzgl dieser 4 Windows-typischen Attribute als unbefriedigend empfinde. Leider ist es wohl so, dass diese Attribute bisher von den exfatprogs gar nicht unterstützt werden, auch nicht in den neuesten Versionen, die bisher noch nicht den Weg in die offiziellen Paketquellen von Ubuntu gefunden haben. Dagegen kann wohl exfat-utils ab Version 1.4 damit umgehen; allerdings gibt es diese Version nicht in den offiziellen Paketquellen von Ubuntu und sie wird es wohl auch nie dahin schaffen, denn als Paket gibt es diese Programmsammlung bei Ubuntu nur bis focal. Ich vermute, dass dieses Paket zu Gunsten von exfatprogs zukünftig ganz entfallen wird.

Andererseits wären für den Praktiker die Attribute readonly und archive durchaus wertvolle und wünschenswerte Hilfsmittel, z.B. archive beim Backup.

Andererseits wären für den Praktiker die Attribute readonly und archive durchaus wertvolle und wünschenswerte Hilfsmittel, z.B. archive beim Backup.

Wenn ich es richtig verstehe, dann können diese Windows-Attribute von der neueren Version von exfat-utils gelesen und manipuliert werden. Doch das heißt ja nicht, dass sie vom Kernel-Modul auch respektiert werden. Was nützen sie dann wirklich?

Was die Abnutzung von Flash-Speichern bei Schreibvorgängen angeht, stimme ich natürlich zu. Doch bei FAT32 ist diese offenbar besonders ausgeprägt, weil wegen der kleinen Cluster und der Fragmentierung die FAT ständig überschrieben wird. Und das sind eben alles Schreibvorgänge an der gleichen Stelle. Was – außer größerer Cluster – in exFAT vielleicht anders ist, weiß ich eben nicht. Es gibt z.B. vermutlich keine technische Notwendigkeit, dass die FAT immer an der gleichen Stelle bleiben muss bzw. immer komplett überschrieben wird. Aber da kenne ich mich viel zu wenig aus. Lies bitte mal, was ich dazu geschrieben habe. Es ist nicht sehr informativ, könnte aber vielleicht das Problembewusstsein etwas schärfen, sodass man nicht immer unbedacht ohne Notwendigkeit "flush" oder "sync" verwendet.

Max-Ulrich_Farber schrieb:

Andererseits wären für den Praktiker die Attribute readonly und archive durchaus wertvolle und wünschenswerte Hilfsmittel, z.B. archive beim Backup.

Wenn ich es richtig verstehe, dann können diese Windows-Attribute von der neueren Version von exfat-utils gelesen und manipuliert werden. Doch das heißt ja nicht, dass sie vom Kernel-Modul auch respektiert werden. Was nützen sie dann wirklich?

Um diese Frage beantworten zu können, müsste man es testen. Da die Funktionalität dieser windows-typischen Attribute aber momentan und absehbar auch für die bald erscheinende Version 24.04 außerhalb des Ubuntu-Universums liegt, werde ich das nicht machen, sondern jemanden überlassen, der diese Attribute wirklich benutzen möchte. Aus meiner Sicht reicht völlig aus: Es geht nicht und es gibt anderswo Ansätze, es zu aktivieren. Es reicht ja normalerweise auch aus, dem um Hilfe rufenden zuzurufen, dass Klopapier im Schrank gebunkert ist statt ihm den Hintern abzuwischen.

Was die Abnutzung von Flash-Speichern bei Schreibvorgängen angeht, stimme ich natürlich zu. Doch bei FAT32 ist diese offenbar besonders ausgeprägt, weil wegen der kleinen Cluster und der Fragmentierung die FAT ständig überschrieben wird. Und das sind eben alles Schreibvorgänge an der gleichen Stelle. Was – außer größerer Cluster – in exFAT vielleicht anders ist, weiß ich eben nicht.

Das Schreiben in Cluster und die FAT sind kein Problem. In die FAT wird sowieso nur beim Anlegen einer Datei oder beim Ändern der Dateigröße geschrieben. Ein großer Cluster reduziert Schreibvorgänge in den Verwaltungsdaten. Wenn ein CLuster tatsächlich geschrieben werden muss, ändert das Betriebssystem des Datenträgers für den Benutzer nicht erkennbar die Zuordnung diese logischen Clusters zu den physischen Sektoren und verhindert so ein Beschreiben der physisch selben Stelle. Man kann als Benutzer nicht zweimal an dieselbe Stelle eines Flash-Datenträgers schreiben. Das hat mit exFAT und sogar mit dem Dateisystem generell nichts zu tun. Kritischer sind z.B. Zeitstempel für den Zugriff, da diese bei jedem Lesen einen Schreibzugriff provozieren. Diese erfolgen zwar auch immer an physisch verschiedenen Stellen, aber die Häufigkeit ist ursächlich für den Tod des Gerätes. ExFAT minimiert einfach per Design die notwendigen Schreibzugriffe und ist deshalb für Flash-Speicher besser geeignet als die alten FAT-Modelle.

[…] das Problembewusstsein etwas schärfen, sodass man nicht immer unbedacht ohne Notwendigkeit "flush" oder "sync" verwendet.

Schaue ich mir mal an.

ExFAT minimiert einfach per Design die notwendigen Schreibzugriffe und ist deshalb für Flash-Speicher besser geeignet als die alten FAT-Modelle.

Ich kann die Details nicht so gut präzisieren wie kB. Dazu fehlen mir einfach die Fachkenntnisse.

Aber wir schreiben ja kein Lehrbuch, sondern "nur" ein Wiki. Ich würde diesen kurzen und klaren Satz von kB gerne genau so übernehmen. Ich denke, der ist gut und hilfreich, und er reicht für die Praxis. Wo und wie diese Minimierung der Schreibzugriffe geschieht, ist zwar sehr interessant, aber für den "Benutzer" letztlich irrelevant.

Um das Wiki lesbar zu halten, müssen wir auch mit "Experten-Boxen" eher sparsam umgehen. Etwas Arbeit dürfen wir ja den Lehrbuch-Autoren noch überlassen. 😉

Es reicht ja normalerweise auch aus, dem um Hilfe rufenden zuzurufen, dass Klopapier im Schrank gebunkert ist statt ihm den Hintern abzuwischen.

Gott sei Dank!

• exFAT verwendet nur eine FAT. Das spart Platz und Verwaltungsaufwand, reduziert aber die Datensicherheit.

Soll der Satz so stehen bleiben? – Ich denke, wir überschätzen den praktischen Wert der zweiten FAT bei FAT32. Ich habe nun versucht, die (sehr umfangreichen!) Dateisystem-Informationen von Microsoft darauf hin durchzusehen und gefunden, dass bei exFAT durchaus gewisse andere Sicherheitsmechanismen eingebaut sind, deren Wirksamkeit ich nicht beurteilen kann. Möglicherweise sind sie auch nicht schlechter (?). "reduziert die Datensicherheit" schreckt verständlicherweise ab. Ich würde einen Satz ähnlich wie

• Auch wenn in exFAT gewisse Mechanismen zur Erhöhung der Datensicherheit eingebaut sind, kann damit doch keine mit einem Journaling-fähigen Dateisystem (z.B. NTFS, ext3 oder ext4) vergleichbare Sicherheit erreicht werden.

vorziehen. Und vielleicht sollten wir dann aus "Vorteile des exFat-Dateisystems" ehrlicherweise "Vor- und Nachteile" machen…

Kurze 8.3-Namen gibt es nicht mehr in der Benutzeroberfläche, sie werden aber intern noch verwendet

Stimmt das so? Ich dachte, bei exFAT würden sie auch intern nicht mehr verwendet.

Ich hatte das Zeitstempel-Problem mit Lösung eingefügt. Aber dabei hatte ich es mir zu leicht gemacht; so einfach ist es offenbar nicht. Ich habe den Abschnitt deshalb wieder herausgenommen – ich muss mich erst noch etwas genauer einlesen. Oder weiß hier jemand genauer Bescheid?

Max-Ulrich_Farber schrieb:

[…] Ich würde diesen kurzen und klaren Satz von kB gerne genau so übernehmen. Ich denke, der ist gut und hilfreich, und er reicht für die Praxis.

Nichts spricht dagegen.

Wo und wie diese Minimierung der Schreibzugriffe geschieht, ist zwar sehr interessant, aber für den "Benutzer" letztlich irrelevant.

Aus Sicht des UbunuUser-de-Wikis sehe ich das auch so. Höchstens Verweise auf andere, weiter führende Seiten wären sinnvoll.

[…]

• exFAT verwendet nur eine FAT. Das spart Platz und Verwaltungsaufwand, reduziert aber die Datensicherheit.

Soll der Satz so stehen bleiben? […]

Der erste ja, ist ja ein Fakt. Der zweite kann weg. Wir müssen uns auf die heikle Beurteilung der Datensicherheit im Vergleich zu anderen Dateisystemen gar nicht einlassen.

Ich würde einen Satz ähnlich wie

• Auch wenn in exFAT gewisse Mechanismen zur Erhöhung der Datensicherheit eingebaut sind, kann damit doch keine mit einem Journaling-fähigen Dateisystem (z.B. NTFS, ext3 oder ext4) vergleichbare Sicherheit erreicht werden.

Nur Fakt nennen: exFAT hat kein Journal.

[…] vielleicht sollten wir dann aus "Vorteile des exFat-Dateisystems" ehrlicherweise "Vor- und Nachteile" machen…

OK

Kurze 8.3-Namen gibt es nicht mehr in der Benutzeroberfläche, sie werden aber intern noch verwendet

Stimmt das so? Ich dachte, bei exFAT würden sie auch intern nicht mehr verwendet.

Ich habe das eingebracht und war dabei im Irrtum. Richtig ist:

• Kurze 8.3-Namen gibt es nicht mehr.