ubuntuusers.de

@Kb:

Dazu kann ich aus bisheriger Beobachtung sagen (noch nicht genügend getestet):

• Ein Zusammenspiel mit Windows gibt es so gut wie gar nicht. Im Gegensatz zu NTFS-3G, wo die Windows-Dateiverwaltung mit SID und (Win-)ACL auch für Linux verwendet wird, bleiben bei NTFS3 SID und (Win-)ACL unberücksichtigt und auch unberührt. NTFS3 legt die Unix-Dateirechte incl. POSIX-ACL "nativ" in den Extended Attributes ab und kennt nur diese. Wie die codiert (nicht gemappt) sind, hat Newubunti ermittelt.

• Man kann einer Datei völlig unabhängig voneinander Dateirechte in Windows und Linux verpassen, gleiche oder auch völlig andere.

• Von NTFS-3G erstellte bzw verwaltete Dateien sind für NTFS3 "Windows-Dateien", da sie ja die gleiche Rechteverwaltung wie diese benutzen.

• Ein ziemlich komplexes Gebiet ist das Zusammenspiel transienter (sog. "simulierter") und persistenter Rechte, da – im Gegensatz zu NTFS-3G – beide Arten innerhalb einer Sitzung koexistieren können. Damit spiele ich gerade herum. Wie werden transiente Rechte persistent? Offenbar durch jeden Schreibvorgang und durch jede Anderung von Rechten mittels chown und chmod. Gilt ein veränderter Zeitstempel grundsätzlich auch als Schreibvorgang?

• Bei den ACL sehe ich (im Gegensatz zu NTFS-3G) keinerlei Handlungsbedarf, da diese – wie auch die UNIX-Dateirechte – in den Extended Attributes zwar codiert, aber als solche eingetragen werden. Sie haben dort gar nichts mit den Win-ACL zu tun. In IMHO korrekter Sprechweise: Rechte und ACL werden zwar codiert, aber nicht auf eine andere Datenstruktur gemappt.

• Die Mount-Optionen sind leider bei den noch aktuellen Kerneln 5.15, 6.2 und 6.5 nicht gleich. Und in 6.9 sollen dann evtl. noch weitere dazukommen (??)

Im Gegensatz zu NTFS-3G gibt es nach meiner Erfahrung weniger große Probleme, aber eine große Menge von "Kleinigkeiten", die vielleicht keine Erklärung, aber zumindest eine Erwähnung brauchen.

Noch eine Beobachtung unabhängig davon: NTFS3 ist anscheinend sehr empfindlich gegen ungeregeltes Aushängen. Eine Erklärung dafür habe ich nicht. Vielleicht werden zur Verminderung von Schreibvorgängen auch Metadaten gepuffert, ich weiß das nicht. Korrumpierte Dateisysteme konnten bisher immer mit chksk /f repariert werden. ntfsfix im Linux wurde nur mit der Option -d überhaupt akzeptiert (wegen des Dirty-Bit).

Wenn du nichts dagegen hast, bringe ich meine Erfahrungen und Beobachtungen als eine Art "Materialsammlung" direkt in den (Baustelle-)Artikel ein. Dort sind sie leichter auffindbar als in der Diskussion und werden deshalb auch eher Andere zum Nachprüfen anregen. Was dann evtl. eher in den Übersichts-Artikel gehört, musst letztlich du entscheiden. Umlagern kann man dann noch immer.

Ist das so in deinem Sinn?

L.G.

Frage: Ist denn gewährleistet, dass in den "Extended Attributes" immer hinreichend Platz frei zur Verfügung steht für die Linux-Rechteverwaltung, oder kann es da "Interessenkonflikte" geben?

Max-Ulrich_Farber schrieb:

Frage: Ist denn gewährleistet, dass in den "Extended Attributes" immer hinreichend Platz frei zur Verfügung steht für die Linux-Rechteverwaltung, oder kann es da "Interessenkonflikte" geben?

Zu 100% sicher kann ich es nicht sagen, hier ist aber eine ausführliche Erklärung zu den EA:

https://superuser.com/questions/396692/what-are-these-extended-attributes-eas-in-the-files-in-windows-8/1736010#1736010

Und hier eine Abhandlung darüber, wie bei NTFS Attribute im allgemeinen gemanagt werden:

https://learn.microsoft.com/de-de/archive/blogs/askcore/the-four-stages-of-ntfs-file-growth

Aus beiden zusammen würde ich zu schließen wagen, dass sich verschieden EA nicht in die Quere kommen sollten, da sie ja in aller Regel ohnehin anwendungsspezifisch eingerichtet werden.

LG, Newubunti

@Kb:

Ich habe nun angefangen, Beobachtungen die sich speziell auf NTFS3 beziehen in den Artikel einzubringen (siehe z.B. "Probleme und Lösungen"…). Ich würde gerne damit fortfahren. Da der Artikel aber noch viele Abschnitte und Aussagen enthält, die sich allgemein auf Windows-Partitionen beziehen, möchte ich diese damit aber keinesfalls durcheinander bringen. Denn ich denke, dass Du diese Abschnitte im Übersichts-Artikel noch gut gebrauchen kannst.

Es wäre IMHO hilfreich, wenn Du diese Passagen zur Sicherheit schon einmal in den Übersichtsartikel kopieren oder übernehmen könntest. Dann kann ich ohne Bedenken die allgemeinen Aussagen durch speziell auf NTFS3 ausgerichtete ersetzen. In erster Linie denke ich dabei an Aussagen zu den transienten ("simulierten") und persistenten ("echten") Dateirechten. Aber auch zu den Mount-Optionen gibt es schon etwas zu sagen.

L.G. Max-Ulrich

Max-Ulrich_Farber schrieb:

[…] Es wäre IMHO hilfreich, wenn Du diese Passagen zur Sicherheit schon einmal in den Übersichtsartikel kopieren oder übernehmen könntest.

Eigentlich war es von mir umgekehrt gedacht: Da ich noch nicht abschätzen konnte, welche Inhalte es aus der alten in die neue Übersicht schaffen, habe ich in dieser Baustelle erst mal alles aus der alten Übersicht gebunkert.

Ich werde jetzt den Artikel Baustelle/NTFS3 inhaltlich bereinigen und alles löschen, was bereits in der neuen Übersicht behandelt wird und m.E. nicht speziell für ntfs3 gilt.

kB schrieb:

[…] Ich werde jetzt den Artikel Baustelle/NTFS3 inhaltlich bereinigen und alles löschen, was bereits in der neuen Übersicht behandelt wird und m.E. nicht speziell für ntfs3 gilt.

Getan.

@Kb:

Ich habe jetzt in den Artikel einiges ’rein geschrieben, was ich inzwischen über den Treiber weiß bzw. zu wissen glaube. Aber bitte sieh das nicht so an, wie wenn ich den Artikel nun übernehmen wollte – ganz und gar nicht! Ich wollte nur meine Erfahrungen und – hoffentlich auch – Erkenntnisse dokumentieren und diese Dir so als Material zur Verfügung stellen. Und da dran mache ich jetzt auch weiter, aber ohne Anspruch auf Vollständigkeit.

Mit NTFS-3G bin ich im Moment fertig. Das heißt nicht, dass ich den Artikel nun als perfekt ansehe. Aber ich denke, er ist jetzt inhaltlich richtig, und das ist auch schon ’mal was. Ich bin dafür, ihn nun so bald wie möglich ins Wiki zurück zu schieben, weil der Artikel so, wie er als "noch gültig" da drin steht, nicht mehr korrekt ist. Wenn dann der Übersichtsartikel und der Artikel für den Treiber NTFS3 stehen, dann kann man ihn nochmal hernehmen, überarbeiten und anpassen. Mit exFAT wird man das dann auch tun müssen.

Ich hatte nie gedacht, dass der Artikel NTFS-3G noch so viel Arbeit machen würde! Und dass es bei dem Thema ein solches Potential für Missverständnisse gibt!

Beste Grüße, Max-Urich

EDIT:

eine beiläufige Frage: Ich habe ’mal im Internet gesucht, wie gebräuchlich die Begriffe "persistent" und "transient" im Deutschen sind. Sehr oft bin ich ihnen nicht begegnet. Würde es nicht besser klingen, wenn wir einfach "dauerhaft" und "temporär" schreiben? "Temporär" ist zwar auch ein Fremdwort, aber doch eher gebräuchlich. Oder hat jemand eine bessere Idee? Es muss doch nicht unbedingt immer alles möglichst englisch klingen!

Das gilt dann natürlich gleichermaßen für NTFS-3G.

Ich habe jetzt den Treiber NTFS3 auf zwei Laptops, beide Xubuntu 22.04 mit Kernel 6.5.0-27 unter normalen, d.h. für Klein-Anwender alltäglichen Bedingungen getestet. Extreme Situationen (extrem umfangreiche Schreibvorgänge, extrem viele gleichzeitig laufende Prozesse, ungeregelte Abbrüche bzw. Unterbrechungen, unzureichender Speicherplatz, konkurrierende Mehrfach-Mounts usw.) konnte und wollte ich nicht nachstellen. Dabei verlief bei mir alles erwartungsgemäß und ohne böse Überraschungen.

Zweimal war nach dem zu frühen Abziehen eines USB-Sticks das Mounten desselben nicht mehr möglich. Nach einer Reparatur mittels chkdsk /f in Windows war alles wieder ok. Eine Reparatur mittels ntfsfix -d unter Linux habe ich erst gar nicht probiert.

Ich arbeite jetzt nach erneuter Überprüfungen meine "Abweichenden Beobachtungen" in die Tabelle der Mount-Optionen ein.

Beim Umgang mit fremden, vornehmlich unter Windows angelegten Dateien, ist noch das Problem der evtl. abweichenden Zeitstempel und der Dateiattribute zu untersuchen. Damit habe ich mich noch gar nicht befasst. Ob hier NTFS3 Besonderheiten aufweist, weiß ich nicht. An sich ist es ja ein generelles Problem bei Windows-Partitionen und wird deshalb wohl im Übersichtsartikel behandelt werden.

Ohne dass ich dies durch Beispiele belegen kann, hatte ich den Eindruck, dass NTFS3 auf Verbindungs-Abbrüche ungewöhnlich empfindlich reagiert (??). Doch ich frage mich, ob wir dies hier überhaupt zu untersuchen haben.

Abgesehen von dem Vorwurf der Instabilität und Unsicherheit, zu dem ich keine Erfahrungen beizusteuern habe, scheint mir NTFS3 sehr einfach und problemlos in der Handhabung zu sein.

L.G.

Max-Ulrich_Farber schrieb:

[…] die Begriffe "persistent" und "transient"

… sind eher fachsprachlich.

[…] Würde es nicht besser klingen, wenn wir einfach "dauerhaft" und "temporär" schreiben?

Mir persönlich erscheinen die zuletzt genannten Bezeichnungen für das Wiki geeigneter als die zuerst genannten.

Max-Ulrich_Farber schrieb:

[…] Ohne dass ich dies durch Beispiele belegen kann, hatte ich den Eindruck, dass NTFS3 auf Verbindungs-Abbrüche ungewöhnlich empfindlich reagiert (??).

Ich habe ein defektes (?) Dateisystem, welches ntfs3 nicht mounten mag, ntfs-3g aber klaglos einbindet. Das mag daran liegen, dass ntfs3 übervorsichtig ist oder dass ntfs-3g nicht vorsichtig genug ist oder es hat andere, mir jedenfalls nicht erkennbare Gründe.

Doch ich frage mich, ob wir dies hier überhaupt zu untersuchen haben.

Seitens des Wikis besteht dafür weder eine Notwendigkeit noch ein Verbot.

Ich habe ein defektes (?) Dateisystem, welches ntfs3 nicht mounten mag, ntfs-3g aber klaglos einbindet.

Das liegt vermutlich am "Dirty Bit". In NTFS-3G ist die Option recover Standard, und da wird das Dirty Bit nicht zur Kenntnis genommen. – Führe ’mal ntfsfix -d (Parameter -d ist wichtig!) aus. Geht es dann wieder mit NTFS3?

Beim Herumexperimentieren mit ntfs3 und ntfs-3g hatte ich das Problem zuweilen auch, dass ntfs3 nicht einhängen mochte. Ich habe dann soweit ich mich erinnere ntfsfix -d ... ausgeführt und dann hat auch ntfs3 wieder einbinden wollen/können.

LG, Newubunti

Weitere gemachte Beobachtungen zu den noch offenen Fragen in folgenden Bereichen:

• Änderungen an vorhandenen Dateien:

  • Die Befehle chown, chgroup und chmod bewirken eine persistente Übernahme der betroffenen Datei-Eigenschaft in die Dateiverwaltung. Dies gilt (anscheinend) selektiv für Besitzer und Modus, d.h. es ist möglich, dass z.B. bei einer Datei der Besitzer (noch) transient, der Modus aber (bereits) persistent ist. Dies gilt auch, wenn die Dateirechte im Dateimanager geändert werden.

  • Eine Änderung des Zeitstempels oder das Beschreiben einer Datei sowie das Ändern des Inhalts eines Ordners ohne Änderung der Besitz- und Zugriffsrechte machen transiente Dateirechte nicht persistent.

• Dateiattribute: Die unter man chattr gelisteten Linux-Dateiattribute werden auf NTFS3-Partitionen nicht verwaltet. Windows-Dateiattribute werden außer durch spezielle Mount-Optionen ebenfalls nicht berücksichtigt.

• Zeitstempel: Die Zeitstempel werden offenbar genau so wie die Zeitstempel von Windows unter NTFS verwaltet und interpretiert.

Weitere noch offene Fragen sind mir im Moment nicht bewusst.

Eine entscheidende Frage bleibt allerdings bestehen: Sind noch weitere relevante Probleme mit dem Treiber bekannt geworden (vor allem Dateisystembeschädigung und verwaiste Dateien), oder kann dieser nunmehr (ab Kernel 6.4) als stabil und sicher gelten?

Ich habe diese Baustelle jetzt als (für mich) fertig beschlossen und stelle sie zur Diskussion vor Freigabe ins Wiki.

Manche während der bisherigen Diskussion aufscheinende Themen bleiben vorläufig unbehandelt. Mir erscheint klüger, diesen Artikel jetzt ins Wiki zu stellen als auf noch unbekannte Antworten zu offenen Fragen zu warten.

Artikel ist jetzt im Wiki. Danke für alle konstruktiven Beiträge, besonders an Max-Ulrich_Farber und Newubunti.

Und danke kB für die gute Zusammenarbeit und auch für die Geduld, die du manchmal für uns aufbringen musstest!