ubuntuusers.de

Max-Ulrich_Farber schrieb:

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.

exfat speichert Zeitstempel nicht so exakt ab

$ stat -c'%y' datei exfat/datei
2024-02-12 09:54:55.430163956 +0100 # datei
2024-02-12 09:54:55.430000000 +0100 # exfat/datei

aber das ist viel besser als vfat, wo die Uhr nur in 2-Sekunden-Schritten tickt

$ stat -c'%y' datei fat32/datei
2024-02-12 09:54:55.430163956 +0100 # datei
2024-02-12 09:54:54.000000000 +0100 # fat32/datei

Bei fat32 braucht man bei rsync dann --modify-window=1 damit diese Dateien nicht ständig neu kopiert werden. Bei exfat scheint es hier keine besonderen Optionen zu brauchen. rsync ist auch so zufrieden. Aber das kommt dann aufs jeweilige Kopierprogramm an...

Ungenaue Zeitstempel können dazu führen, daß tatsächliche Änderungen ignoriert werden, wenn sich der Dateiinhalt innerhalb des Zeitfensters ändert. Das ist letztendlich ein unlösbares Problem, solange man sich allein auf Dateigröße und Zeitstempel zum Abgleich verlässt.

Manche Dateisysteme speichern einfach keine richtigen Zeitstempel. Kann man nichts machen.

Max-Ulrich_Farber schrieb:

[…] Zeitstempel […] weiß hier jemand genauer Bescheid

Das exFAT-Dateisystem ermöglicht in den Verzeichnis-Einträgen 3 Zeitstempel, diese sind vorgesehen für Geburt, letztes Schreiben und letzten Zugriff (lesend oder schreibend). Alle drei Zeitstempel haben 32 Bit zur Speicherung des Zeitpunktes (Datum und Zeit) mit einer Genauigkeit von 2 Sekunden, bei Geburt und letzter Schreibzugriff gibt es ein weiteres Byte für einen Zuschlag mit einer Auflösung von 10ms. Alle drei Angaben sind zu verstehen als lokale Zeit und es gibt jeweils noch ein weiteres Byte zur Darstellung des Offsets zur UTC mit einer Auflösung von 15 Minuten.

Man muss aber unterscheiden zwischen den grundsätzlichen Möglichkeiten des Dateisystems und der Verfügbarkeit der jeweiligen Eigenschaften in der Software.

Linux kennt 4 Zeitstempel, da beim Schreiben unterschieden wird zwischen Schreiben des Dateiinhaltes und Schreiben der Verwaltungsdaten. Die Implementation des Geburtszeitpunktes in der Betriebssystem-Software (nicht im Dateisystem!) war lange fehlerhaft und wurde erst kürzlich verbessert; per stat lässt sich das inspizieren.

Dank der technischen Unterschiede bei Darstellung und Behandlung von Zeitstempeln sind fast beliebige Überraschungen möglich, wenn man ein exFAT-Dateisystem (wie ähnlich auch bei FAT und NTFS) wechselweise an Linux oder Windows anschließt.

Ja, ich habe inzwischen auch gemerkt, dass das Zeitstempel-Problem ein Wespennest ist!

Fazit: Ich will mich jetzt nicht mehr damit befassen. Bisher stand darüber nichts im Artikel, und so kann das dann notfalls halt bleiben. Besser, man schreibt nichts, als ’was Falsches.

Ich bin bereit, noch einen kurzen Hinweis anzubringen, sozusagen als Warnung: Da gibt es etwas, worauf man nötigenfalls achten muss. Und aus meiner Sicht muss das dann eben genügen.

Damit wäre dann, was mich betrifft, der Artikel wohl wieder "rückschiebbar".

Etwas off topic:

Dass rsync offenbar mit exFAT klarkommt, ist erfreulich. Auch das GUI-Programm FreeFileSync, das ich gerne verwende, kam bei mir mit ext4 auf NTFS und auch ext4 auf exFAT gut klar, auch wenn ich den Zeitstempel als Unterscheidungsmerkmal zuließ. Auch dann, wenn sich beim Kopieren der (scheinbare) Besitzer änderte – bei Windows-Dateisystemen kann das ja sein – ging es mit exFAT; bei NTFS arbeite ich immer mit "permissions". Von FAT32 lasse ich dabei inzwischen lieber die Finger weg.

EDIT:

Kann man die "entschärften" Aussagen zu den Zeitstempeln so stehen lassen? Auch die Aussagen zur Datensicherheit habe ich entschärft.

Max-Ulrich_Farber schrieb:

[…] Damit wäre dann, was mich betrifft, der Artikel wohl wieder "rückschiebbar". […] Kann man die "entschärften" Aussagen zu den Zeitstempeln so stehen lassen?

Abgesehen vom Satz,

Wenn Dateinamen auch unter Windows problemlos lesbar sein sollen, dann ist ihre Länge für den ganzen Pfad (!) auf 256 Zeichen zu beschränken. In Linux-Dateisystemen sind dies üblicherweise 4096 Byte. Zu beachten ist, dass Sonderzeichen auch mehrere Byte belegen können.

der mir bzgl. der konkreten Zahlen nicht ganz richtig erscheint, ich aber selbst nicht aus meiner Erinnerung korrigieren könnte, habe ich keine Änderungswünsche oder Ergänzungen.

Die Links habe ich aber noch nicht überprüft.

Hallo,

die Aussage zur Länge ist auch in der Form falsch. Die max Länge des kompletten Pfads ist 32.760 Unicodezeichen, wobei die Komponenten (also die einzelnen Pfadnamen und der Dateiname) nicht länger als 255 Unicodezeichen sein dürfen. Quelle: Microsoft, siehe https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison#limits.

Gruß, noisefloor

noisefloor schrieb:

[…] die Aussage zur Länge ist auch in der Form falsch. Die max Länge des kompletten Pfads ist 32.760 Unicodezeichen, wobei die Komponenten (also die einzelnen Pfadnamen und der Dateiname) nicht länger als 255 Unicodezeichen sein dürfen.

Danke für die Richtigstellung. Dann entfernen wir die Aussage zur Pfadlänge am besten ganz aus dem Artikel.

Quelle: Microsoft, siehe https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison#limits.

Danke für den hilfreichen Link, der noch eingearbeitet wird.

Zur Längre von Pfad- und Dateinamen habe ich jetzt langsam so viel Widersprüchliches gelesen, dass ich mich damit nicht weiter befassen will. Was das Dateisystem angeht, ist der von noisefloor angegebene Link ja ganz klar, und wie Windows damit umgeht, kann uns eigentlich ziemlich egal sein. Das ist dann ja, wenn überhaupt, eine Frage der Treiber und nicht des Dateisystems. Siehe dazu auch https://learn.microsoft.com/de-de/windows/win32/fileio/maximum-file-path-limitation?tabs=registry.

Anscheinend vertragen einzelne Anwendungen (darunter auch der Explorer?) auch nicht, dass längere Pfadnamen als 255 Zeichen "am Stück" angegeben werden; man muss sich angeblich durch die Ordnerstruktur in "Portionen" mit maximal 255 Zeichen "durchhangeln". Doch ob das wirklich stimmt, weiß ich auch nicht. Das ist aber auch letztlich nicht unser Problem.

Wie kB sagt, lassen wir alle Aussagen zur maximalen Pfadlänge besser ganz weg. Ist unnötiger Ballast.

… Link, der noch eingearbeitet wird.

Ich denke, da geht es wohl nur noch um die Pfadlänge (?), und die wollen wir ja ganz entfernen. Von den "zusätzlichen Sicherheitsvorkehrungen" bei exFAT finde ich in dem Link nur die Prüfsumme für Metadaten. Diese würde ich lieber nicht explizit erwähnen, denn ich habe keine Ahnung, wie wirksam diese ist. Sonst steht doch wohl alles für uns Relevante davon schon im Artikel (?)

EDIT:

Auch beim obigen Pfad liest man besser das Original; die Übersetzung ist schrecklich! (Germany is not an important country…)

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Hallo zusammen!

→ unterschiede-windows-linux/

Vorschlag::

• exFAT (Abschnitt „Dateinamen“), Ergänzung der letzte Satz:

  • Wenn Dateinamen auch unter Windows problemlos verwendbar sein sollen, dann empfiehlt es sich, ihre Länge für den ganzen Pfad auf 255 Zeichen zu beschränken.

  • →

    • Wenn Dateinamen auch unter Windows problemlos verwendbar sein sollen, dann empfiehlt es sich, ihre Länge für den ganzen Pfad auf 255 Zeichen zu beschränken.

    • Siehe Dateisystem (Abschnitt „Hinweise“).

linux_joy schrieb:

[…] Vorschlag::

• exFAT (Abschnitt „Dateinamen“), Ergänzung der letzte Satz: […]

Siehe Dateisystem (Abschnitt „Hinweise“)

Ich denke darüber nach, bin aber eher skeptisch, ob dem Leser hier ein Verweis auf diffizile technische Details wirklich helfen würde, das unappetitliche Thema unterschiedlicher zulässiger Pfadlängen in unterschiedlichen Situationen bei unterschiedlichen Betriebssystemen, und das auch noch versionsabhängig wirklich besser zu erfassen.

Momentan bin ich der Meinung, die nackte Praxisempfehlung reicht aus und verwirrt hier ohne Verweis weniger als mit dem von Dir vorgeschlagenen Verweis.

Hallo kB, Du schriebst:

linux_joy schrieb:

[…] Vorschlag::

(...)

Ich denke darüber nach, bin aber eher skeptisch, ob dem Leser hier ein Verweis auf diffizile technische Details wirklich helfen würde, das unappetitliche Thema unterschiedlicher zulässiger Pfadlängen in unterschiedlichen Situationen bei unterschiedlichen Betriebssystemen, und das auch noch versionsabhängig wirklich besser zu erfassen.

Momentan bin ich der Meinung, die nackte Praxisempfehlung reicht aus und verwirrt hier ohne Verweis weniger als mit dem von Dir vorgeschlagenen Verweis.

Ja, Deine Meinung ist auch nicht ohne...

Falls Du es Dir doch noch anders überlegen solltest, die von mir vorgeschlagene Ergänzung sollte dann natürlich ohne Fettschrift platziert werden!

Hallo zusammen!

Betr. exFAT (Abschnitt „Formatieren-und-Pflege-des-Dateisystems“): In der Diskussion des Artikels UUID habe ich bereits geschrieben, dass es doch mit dem Paket exfatprogs wohl bereits seit Ubuntu 22.04 mit den beiden Programmen tune.exfat und exfatlabel 2 passende Werkzeuge für das Anzeigen und Bearbeiten des des Dateisystem- (und nicht des Datenträger-)Labels gibt, zumindest unter Ubuntu 24.04 (tune.exfat ist erst später hinzugekommen). Die Dateisystem-Serienkennung kann man mit beiden Tools ebenfalls anzeigen und ggf. auch ändern (lassen).

exfatlabel könnte hier also ergänzt werden.