ubuntuusers.de

Hallo,

aus den vielen Seiten Diskussion zu dem Artikel ntfs-3g kann man für das Einhängen, in diesen Artikel die folgenden Erkenntnisse übernehmen (das ist erst mal nur als Material-Sammlung gedacht). Außerdem geht die Aufstellung nicht auf den Mischbetrieb von ntfs3 und ntfs-3g ein:

sudo ln -sv /usr/sbin/ntfs-3g /usr/sbin/mount.ntfs 

Beobachtung

Die Unterschiede zwischen den Treibern NTFS-3G und NTFS3 sind anscheinend erheblicher als ich angenommen hatte. Sie betreffen offenbar nicht nur das Einhängen, sondern auch die Art, wie Dateiattribute jeweils im Dateisystem realisiert werden.

• Dass die Benutzer- und Rechteverwaltungen nicht kompatibel sind, wurde schon festgestellt.

• Beide Treiber unterstützen Symlinks. Aber Symlinks, die mit einem der Treiber angelegt wurden, werden vom jeweils anderen Treiber nicht als solche erkannt. Das gilt sowohl für Symlinks innerhalb des NTFS-Dateisystems als auch für solche aus diesem heraus.

• in NTFS-3G und in Windows können jeweils Symlinks eingerichtet werden. Diese anerkennen einander aber nicht. Wie sieht es diesbezüglich mit NTFS3 und Windows aus?

• Bei NTFS-3G werden je nach Optionen Benutzer und Dateirechte entweder simuliert oder persistent eingerichtet. Beides nebeneinander ist nicht möglich. NTFS3 verhält sich diesbezüglich offenbar anders: simulierte (transiente) und echte (persistente) Dateirechte können offenbar koexistieren, und transiente Dateirechte können offenbar mittels chown und chmod in persistente übergeführt werden. Dies habe ich aber noch nicht hinreichend recherchiert.

• Bei NTFS3 haben Dateien, die in Windows oder mit NTFS-3G angelegt wurden, keine persistenten Besitzer- und Dateirechte, und diese werden dann beim Einbinden zunächst mittelds uid und gid simuliert bzw. beim Fehlen der Optionen durch 0 = Root ersetzt. Sie können aber anschließend zugeteilt werden. Frage: Beeinträchtigt die Zuteilung persistenter Dateirechte ggf. die SID von Windows? In NTFS-3G wäre dies nämlich ohne User-Mapping der Fall!

• NTFS3 kennt kein User-Mapping. Frage: Können ein und derselben Datei in beiden Systemen unabhängig voneinander (persistente) Besitz- und Dateirechte zugeteilt werden,oder macht die Zuteilung von persistenten Dateirechten in einem System ggf. die im anderen System kaputt? (Verhalten von NTFS-3G ohne User-Mapping)

Bei NTFS-3G ist hinreichend bekannt, wie die uid und gid im Dateisystem persistent realisiert werden. Sie werden in unter Windows nicht zugeordnete SID (ohne User-Mapping) oder in Windows den gleichen Besitzern zugeordnete SID (mit User-Mapping) übertragen. Das Prinzip ist verständlich und durchschaubar. Es hat den Nachteil, dass die Windows- und Linux-Rechteverwaltungen nicht koexistieren können, ohne einander zu beeinträchtigen.

Frage: Wie realisiert NTFS3 die persistente Zuordnung von uid und gid zu einer Datei? Gibt es da auch einen anderen Weg als die Zuordnung einer Windows-SID? Wie wirkt sich dies ggf. aus?

Noch gar nicht untersucht habe ich Hardlinks mit beiden Treibern. Außerdem gibt es noch weitere, noch nicht untersuche Fragen. – Aber unabhängig davon steht schon fest: Es ist äußerst problematisch, zwischen den Treibern hin und her zu wechseln!!

Leider gibt die Dokumentation von NTFS3 bei all diesen Fragen wenig her (im Gegensatz zu NTFS-3G).

Gruß – Max-Ulrich

Max-Ulrich_Farber schrieb:

Beobachtung […] Außerdem gibt es noch weitere, noch nicht untersuche Fragen.

… und es werden täglich mehr.

unabhängig davon steht schon fest: Es ist äußerst problematisch, zwischen den Treibern hin und her zu wechseln!!

Uneingeschränkte Zustimmung!

Deshalb gehört auch in den Wiki-Artikel zu ntfs-3g und ntfs3 jeweils eine fette Warnung, grundsätzlich und immer nur eines von beiden zu verwenden. Jedenfalls bei schreibendem Zugriff.

Für die Wiki-Artikel sollten wir zunächst unterstellen, dass kein Mischbetrieb erfolgt.

Die bei Mischbetrieb wechselweise auftretenden Effekte und Schäden sollte man erst später diskutieren, wenn wir für beide Situationen getrennt erst mal valide Artikel haben.

Deshalb ist es aus meiner Sicht auch äußerst wichtig, als Anwender sicher steuern zu können, dass immer nur die gewünschte Variante zur Anwendung kommt.

Das mit den Symlinks kannte ich noch nicht. ntfs-3g verwendet da IntxLNK, ntfs3 nicht.

Das Problem scheint generell zu sein, daß Windows bei Symlinks den Laufwerksbuchstaben erwartet. Aber unter Linux ist der Buchstabe unbekannt. ntfs3 ignoriert den Buchstaben einfach (und erwartet/unterstützt keine Links zu anderen Laufwerken). Und ntfs-3g verwendet denn eben diese IntxLNK Dinger die selbst unter Windows nicht richtig unterstützt werden.

Am besten man verzichtet darauf eigene Symlinks zu erstellen...?

Für die Wiki-Artikel sollten wir zunächst unterstellen, dass kein Mischbetrieb erfolgt.

Ja, sonst werden wir überhaupt nicht mehr fertig, und die Seitenzahlen in der Diskussion werden dreistellig!

Deshalb ist es aus meiner Sicht auch äußerst wichtig, als Anwender sicher steuern zu können, dass immer nur die gewünschte Variante zur Anwendung kommt.

Ganz genau meine Ansicht! 👍 Ebenso wichtig ist wohl auch, für den Übergang auf NTFS3 praktische Hilfestellung zu geben, denn dies wird für die meisten bedeutsam werden.

Deshalb sollten wir jetzt vielleicht bei manchen zwar interessanten, aber doch peripheren Details bei NTFS-3G (z.B. wie man es machen kann, dass unprivilegierte Benutzer, die die Partition ja gar nicht einbinden sollten, dies trotzdem tun können…) etwas Mut zur Lücke zeigen und uns jetzt hier den Problemen zuwenden, bei welchen schon dutzendweise Fehler vorprogrammiert sind! Denn wenn jetzt NTFS3 Standard ist, dann haben praktisch alle bisherigen Benutzer von NTFS-3G mit Problemen zu rechnen!

Mein Vorschlag: Sehen wir, dass wir möglichst schnell NTFS-3G abschließen. Da gibt es ja außerdem eine recht umfangreiche Dokumentation 🇬🇧, und englisch kann man, oder man kann es lernen. Bei NTFS3 tappen wir noch sehr im Dunkeln! Und das ist jetzt (IMO leider zu früh) Standard. Das ist jetzt das aktuelle Problem!

Gruß – M.-U.

frostschutz schreibt:

Am besten man verzichtet darauf eigene Symlinks zu erstellen...?

Das können wir nicht machen. Symlinks sind in Linux ein so verbreitetes und selbstverständliches Mittel, dass wir uns unbedingt damit befassen müssen. – Wieviele Symlinks hast du in deinem Homeverzeichnis? Ich kann meine nicht zählen…

Die Lösung, bei Linux-Symlinks Windows außen vor zu lassen, finde ich hingegen akzeptabel. Ich habe sowieso den Eindruck (kann dies aber bis jetzt noch nicht belegen), dass NTFS3 im gleichen Dateisystem eine konsequentere Trennung von Windows und Linux ermöglicht bzw.bewirkt. Ich habe eine Dual-Boot Maschine mit der ich etwas experimentieren könnte. Aber die will ich mir auf gar keinen Fall zerschießen! Ein Dual-Boot neu aufsetzen, nein danke! 😬

ntfs3 ignoriert den Buchstaben einfach (und erwartet/unterstützt keine Links zu anderen Laufwerken)

Das mit dem Buchstaben weiß ich nicht, aber innerhalb von Ubuntu-Linux haben bei mir Symlinks zu andern Laufwerken mit "echten" Linux-Dateisystemen (ext4) schon geklappt. Ich nehme ’mal an, dass die auch persistent sind (?).

L.G. – M.-U.

Max-Ulrich_Farber schrieb:

frostschutz schreibt:

Am besten man verzichtet darauf eigene Symlinks zu erstellen...?

Das können wir nicht machen. Symlinks sind in Linux ein so verbreitetes und selbstverständliches Mittel, dass wir uns unbedingt damit befassen müssen.

Symlinks sind in den Dateisystemen, welche sie unterstützen, ganz einfach Dateien eines bestimmten Typs. Genau wie in den regulären Dateien lassen sich darin beliebige Texte speichern, auch Texte beliebiger Länge. Bei langen Texten bieten aber Symlinks keinerlei Vorteile gegenüber regulären Dateien, weshalb man das in der Praxis nicht macht. Bei kurzen Texten hat dagegen ein Symlinks den Vorteil gegenüber einer regulären Datei, dass ein Symlink keinen Speicherblock belegt, weil der Dateiinhalt im inode der Datei abgelegt werden kann. Das nutzt man verbreitet zur Ablage von Dateipfaden.

Die Nutzung solcher Notizen erfordert eine Interpretation durch die Shell und ist von dieser abhängig, d.h. es macht nur dann Sinn, einen Symlink mit einem Dateipfad zu erzeugen, wenn erzeugende und interpretierende Shell dieselben Vorstellungen haben. Linux- und Windows-Shells haben aber nun einmal unterschiedliche Vorstellungen, wie ein Dateipfad auszusehen hat – man darf daher nicht erwarten, das Symlinks im fremden System so wie im eigenen System interpretiert werden.

Wer Symlinks verwenden will, muss das verstanden haben. Um Ärger zu vermeiden, verzichtet man am besten auf ihre Erstellung im fremden Dateisystem.

Max-Ulrich_Farber schrieb:

• Beide Treiber unterstützen Symlinks. Aber Symlinks, die mit einem der Treiber angelegt wurden, werden vom jeweils anderen Treiber nicht als solche erkannt. Das gilt sowohl für Symlinks innerhalb des NTFS-Dateisystems als auch für solche aus diesem heraus.

• in NTFS-3G und in Windows können jeweils Symlinks eingerichtet werden. Diese anerkennen einander aber nicht. Wie sieht es diesbezüglich mit NTFS3 und Windows aus?

Das stimmt nicht ganz.
Von Windows angelegte echte Symlinks und auch die Pseudoform "Junction" werden von NTFS-3G korrekt erkannt, sofern es sich um relative handelt, und die auf das gleiche Dateisystem verweisen.
Da dies so funktioniert, habe ich schon vor langer Zeit beim Entwickler Jean-Pierre André angeregt, dass NTFS-3G doch auch solche Windows-kompatiblen Symlinks anlegen könnte, sofern die relativ und auf das gleiche Dateisystem verweisend sind. Ich bekam die Antwort, dass es eine experimentelle Version von NTFS-3G gäbe, die das so macht, aber da gäbe es dann andere Einschränkungen, die ich nicht wirklich verstanden hatte (bzw. ich nicht tief genug reingegangen bin). Deshalb würde er das nicht in die offiziellen Releases einbauen.
Auch für von Windows angelegte absolute und Dateisystem-übergreifende relative Symlinks gibt es (teilweise) Lösungen. Dafür muss im Ordner .NTFS-3G neben dem User-Mapping noch ein Volume-Mapping angelegt werden. Leider finde ich die dazugehörige Doku im Moment nicht.

Das geschriebene bezieht sich auf den Stand von vor ca. 10..14 Jahren, als ich auch selber noch mit dem Source-Code beschäftigt war, und auch Patches eingebracht habe. Wie weit das alles heute noch gilt, weiß ich nicht genau.

Noch gar nicht untersucht habe ich Hardlinks mit beiden Treibern.

Hardlinks sind unproblematisch, allein schon deshalb, weil sie ja nur innerhalb eines Volumes möglich sind. Hardlinks sind ja nichts anderes, als zusätzliche Verzeichniseinträge, die auf denselben Inode verweisen. So müssen sie zwangsläufig kompatibel sein.

UlfZibis schrieb:

Auch für von Windows angelegte absolute und Dateisystem-übergreifende relative Symlinks gibt es (teilweise) Lösungen. Dafür muss im Ordner .NTFS-3G neben dem User-Mapping noch ein Volume-Mapping angelegt werden. Leider finde ich die dazugehörige Doku im Moment nicht.

https://github.com/tuxera/ntfs-3g/wiki/Junctions-Points,-Symbolic-Links-and-Reparse-Points

Danke, kannte ich auch noch nicht.

Dafür muss im Ordner .NTFS-3G neben dem User-Mapping noch ein Volume-Mapping angelegt werden.

Da halte ich es bei Symlinks, ehrlich gesagt, lieber mit kB:

Um Ärger zu vermeiden, verzichtet man am besten auf ihre Erstellung im fremden Dateisystem.

Ärger haben wir auch so schon genug. – Aber die Möglichkeiten von Symlinks innerhalb von Linux würde ich schon gerne voll ausnützen.

Neu ist mir nun, dass offenbar innerhalb von Linux auch der andere Dateisystem-Treiber in diesem Sinne ein "fremdes Dateisystem" ist.

UlfZibis schrieb:

Von Windows angelegte echte Symlinks und auch die Pseudoform "Junction" werden von NTFS-3G korrekt erkannt, sofern es sich um relative handelt, und die auf das gleiche Dateisystem verweisen.

Auch umgekehrt? – In Windows kenne ich mich sehr wenig aus. Was sind dort echte und unechte Symlinks?

Hier ein Link:

https://superuser.com/questions/343074/directory-junction-vs-directory-symbolic-link

Aber das alles will ich jetzt gar nicht verstehen. In dieses Wespennest steche ich nicht hinein.

Denn wollen wir uns jetzt nicht auf die Probleme innerhalb von Linux konzentrieren und Symlinks von und nach Windows (erst mal) außen vor lassen? Sonst verlieren wir uns (auch hier wieder) in Details, wo doch noch ganz elementare praktische Probleme anstehen.

Max-Ulrich_Farber schrieb:

Dafür muss im Ordner .NTFS-3G neben dem User-Mapping noch ein Volume-Mapping angelegt werden.

Da halte ich es bei Symlinks, ehrlich gesagt, lieber mit kB:

Um Ärger zu vermeiden, verzichtet man am besten auf ihre Erstellung im fremden Dateisystem.

Dieses Mapping ist aber nicht für das "Erstellen" gedacht, sondern nur für das lesende Übersetzen von solchen Links.

Von Windows angelegte echte Symlinks und auch die Pseudoform "Junction" werden von NTFS-3G korrekt erkannt, sofern es sich um relative handelt, und die auf das gleiche Dateisystem verweisen.

Auch umgekehrt?

Eben leider (aktuell noch) nicht, wie ich schrieb. Steht auch so in dem Link von frostschutz.

Was sind dort echte und unechte Symlinks?

Unechte sind die verschiedenen Varianten von Junctions und die sogenannten "Verknüpfungen". Die Echten waren schon immer in NTFS vorgesehen, aber erst mit Windows Vista gab es auch Werkzeuge, sie zu benutzen. Mit der LSE konnte man sie sogar schon unter Windows XP benutzen.

... und Symlinks von und nach Windows (erst mal) außen vor lassen?

Jain, also zumindest bitte nichts falsches bzgl. Symlinks in den Artikel schreiben.

UlfZibis schrieb:

Hardlinks sind unproblematisch, allein schon deshalb, weil sie ja nur innerhalb eines Volumes möglich sind. Hardlinks sind ja nichts anderes, als zusätzliche Verzeichniseinträge, die auf denselben Inode verweisen. So müssen sie zwangsläufig kompatibel sein.

Hach, es gibt doch eine gewisse Einschränkung. Windows erlaubt die Erstellung nur für Dateien, nicht für Verzeichnisse (Grund ist glaube ich die Unterbindung von Endlosschleifen). NTFS-3G erlaubt das aber schon. Unter Windows werden die – soweit ich mich erinnern kann – dann auch akzeptiert.

zumindest bitte nichts falsches bzgl. Symlinks in den Artikel schreiben.

Deshalb lieber möglichst pragmatisch bleiben und unsichere, auf Vermutungen basierende "Erklärungen" möglichst vermeiden: Das geht so, und dies geht nicht… Warum es so ist, können wir erst dann sagen, wenn eine ausreichende Dokumentation da ist.

Eine andere Frage: Nachdem die Installation des HWE Kernels 6.5 unter Xubuntu 22.04 auf einem meiner beiden Laptops so problemlos geklappt hat, möchte ich dies auch auf dem anderen (Dual Boot, Xubuntu 22.04, Kernel 5.15) machen. Brauchen wir noch irgendwelche Informationen aus einem (immer noch aktuellen) LTS-System mit dem alten Kernel? Bei NTFS3 könnte das schon der Fall sein, da das Kernel-Modul dazwischen weiter entwickelt wurde (Beispiel windows_names). Hat jemand von euch dafür noch einen Kernel vor 6.2 in Betrieb?

Ich habe mir jetzt mittels gparted einen hinreichend großen USB-Stick in NTFS formatiert und experimentiere nun zunächst nur mit diesem. An interne NTFS-Dateisysteme, vor allem an die Windows-Systempartition meines Dual Boot Systems, wage ich mich nicht heran (das ist begründetes Misstrauen, keine Feigheit!). Ich habe dabei gestern (nein, es war schon heute) bis tief in die Nacht hinein mehr oder weniger zufällig manche interessante Beobachtungen gemacht. Ich will nun etwas systematischer vorgehen.

Als Test-System stehen mir zur Verfügung (alles betagte Hardware…)

1. Thinkpad L520, Xubuntu 22.04 mit neuestem HWE-Kernel 6.5

2. Thinkpad T530, Xubuntu 22.04 LTS mit Kernel 5.15

3. Thinkpad T530, Windows 10 pro (im Dual-Boot mit 2.) 🇩🇪

Ich bemühe mich, bei meinen Versuchen möglichst so vorzugehen, wie dies ein "gewöhnlicher" Benutzer tut, d.h. ich arbeite so weit wie möglich mit der GUI und in Linux mit den Dateimanagern Nautilus und Thunar (GTK). Dabei erhalte ich (vor allem auch in Windows) viele Informationen in graphischer Form.

Bildschirm-Kopien in diesen Thread einzufügen ist, wenn überhaupt (?), nur mit viel Aufwand möglich. Deshalb habe ich in meiner privaten Magenta Cloud einen Ordner eingerichtet, zu dem jedermann über folgenden Link über den Internet-Browser lesend (kein Schreibrecht!) Zugang hat:

https://magentacloud.de/s/Aa6wcYbJRqCWwcQ

Ich vertraue auf die Sicherheits-Versprechen der Deutschen Telekom 😇 und verzichte deshalb auf ein zusätzliches Kennwort. Ich behalte mir natürlich vor, nötigenfalls die URL zu ändern und ein Kennwort festzulegen oder auch den öffentlichen Zugang ganz zu sperren.

Um diesen Thread nicht zu überlasten, werde ich im Laufe der Zeit in diesem Link zusätzliche Beobachtungen und Versuche nötigenfalls mit Bildschirm-Kopien ablegen (zurzeit ist er noch leer 🙄 ).

Gruß – Max-Ulrich

Ich kann schon ’mal erste Ergebnisse zusammenfassen. Bildschirm-Kopien dazu kann ich nötigenfalls später liefern. Ich bin folgendermaßen vorgegangen:

1. Ich habe auf dem mittels Kernel-Treiber NTFS3 (Kernel 6.5) eingebundenen Stick in einem Ordner NTFS3 einige Dateien angelegt. Dann habe ich die Dateien in einen anderen Ordner kopiert und dort Besitzer und Zugriffsrechte verändert (nur UNIX-Dateirechte, keine ACL)

2. Nun habe ich den Stick in Windows 10 eingebunden und dort die Dateien verglichen. Die Einträge unter "Sicherheit" sind exakt gleich geblieben: als Benutzer nur "Jeder" mit Vollzugriff. In Windows ist von den Linux-Rechten nichts zu erkennen, weder Besitzer noch Zugriffsbeschränkungen.

3. Ich habe nun in Windows Besitz- und Zugriffsrechte verändert und den Stick anschließend wieder mit dem gleichen Treiber NTFS3 in Linux eingebunden. Dort waren keine Veränderungen zu erkennen.

4. Nun habe ich den Stick mittels FUSE-Treiber NTFS-3G mit der Option permissions wieder in XUbuntu eingebunden und einen Ordner NTFS-3G angelegt. Dort bin ich anschließend genau entsprechend wie in 1. vorgegangen.

5. Dann habe ich den Stick wieder in Windows eingebunden und die Einträge in "Sicherheit" verglichen. Genau wie erwartet, haben diese sich durch die im Linux vorgenommenen Änderungen von Besitzer und Zugriffsrechten verändert. Für Besitzer und Gruppe wurde von NTFS-3G eine "zufällige" Windows-SID angelegt, und dieser wurden die in Linux festgelegten persistenten Dateirechte übertragen. Der Vorgang heißt bei NTFS-3G "default user mapping". Sowohl SID als auch Zugriffsrechte waren nach Änderung unter Linux auch in Windows anders geworden.

6. Entsprechend zu 3. habe ich nun wieder in Windows Dateirechte verändert und diese mit dem gleichen Treiber HTFS-3G in Linux überprüft. Wie erwartet haben sich diese auch dort entsprechend zu den Veränderungen in Windows verändert.

(Nebenbei geht der "Zufall" manchmal eigentümliche Wege: Die beim "default user mapping" zufällig generierte SID stimmt bis auf die vier letzten, entscheidenden Ziffern exakt mit der Ziffernfolge der Kreiszahl Pi=3,14159265…… überein 😛 )

Der Treiber NTFS-3G repräsentiert nach meinen bisherigen, unvollständigen Beobachtungen aus der Sicht von NTFS3 ein Windows-Dateisystem und wird (weitgehend?) wie ein solches behandelt. Dies muss aber noch genauer untersucht werden.

Die Vorgänge waren reproduzierbar, und die Beobachtungen bestätigen genau meine Vermutung, dass die beiden Treiber NTFS3 und NTFS-3g für die Verwaltung von Linux-Dateirechten grundsätzlich verschiedene Wege gehen:

• NTFS-3G verwendet die Rechteverwaltung von Windows (bzw. initiiert eine solche, falls noch nicht vorhanden) und überträgt uid und gid auf eine "zufällige" (default user mapping) oder über eine Datei zugeordnete SID. Für die Unix-Zugriffsrechte werden Windows-ACL verwendet.

• mit NTFS-3G kann man somit die im einen Betriebssystem festgelegten persistenten Dateirechte auch vom jeweils anderen Betriebssystem aus erkennen und auch verändern. Dies ist bedingt in beide Richtungen möglich, weil auch beim default user mapping die verwendete SID in Windows bekanntgegeben wird. Beim default user mapping sind allerdings die SID der übrigen, unter Windows eingerichteten Benutzer in Linux unbekannt und können dort AFAIK auch nicht ermittelt werden ("Windows erfährt alles, Linux aber nicht").

• Bei NTFS3 ist die Benutzer- und Rechteverwaltung in Linux offenbar völlig von Windows unabhängig, und auch beim Einrichten persistenter Rechte bleiben Windows-SID und -ACL unberührt bzw. es werden gar keine festgelegt.

Ohne dieses untersucht zu haben, gehe ich einmal davon aus, dass sich hieran nichts Wesentliches ändert, wenn man bei NTFS-3G statt der Option permissions die Option acl und bei NTFS3 zusätzlich die Option acl verwendet.

Ohne die nötige Schärfe in der Ausdrucksweise kann man dies wohl so beschreiben: NTFS-3G verwendet von Linux aus das Windows-Dateisystem NTFS, ggf. mit seiner kompletten Windows-Rechteverwaltung. NTFS3 bietet hingegen mit den Mitteln von NTFS ein eigenes, unabhängiges Linux-Dateisystem an, das ggf. auf dem Datenträger bzw. der Partition mit dem Windows-Dateisystem koexistiert. Das Vorgehen von NTFS-3G ist leicht durchschaubar. Wie aber NTFS3 dies technisch verwirklicht, kann ich mir noch gar nicht vorstellen. Offenbar gibt es in den Metadaten für so etwas noch genügend freien Platz (??).

Gruß – M.-U.

EDIT: (13.03.,23:50)

Im Cloud-Ordner (s.o.) https://magentacloud.de/s/KQrQ4fgfTbYfFqj (geändert) befinden sich jetzt mit heutigem Datum Bildschirm-Kopien der in Windows 10 angezeigten Eigenschaften/Sicherheit der ursprünglich gleichen Datei, mit NTFS3, dann mit NTFS-3G (default user mapping) und dann wieder mit NTFS-3G, aber mit veränderten Dateirechten (default user mapping, Besitzer, Gruppe und Unix-Dateirechte geändert), auf den USB-Stick geschrieben.

EDTT: (14.03.,10:00)

Ich bleibe im gleichen Post, ich diskutiere ja größtenteils mit mir selber 🙄

Ich will jetzt an der Oberfläche bleiben und nur die Beobachtungen beschreiben, ohne den Versuch, diesen auf den Grund zu gehen:

• Zum Zusammenspiel mit Windows gibt es nicht mehr viel zu sagen. Das Thema windows_names ist wohl erledigt. Sonst gibt es nur (?) noch das Thema Symlinks, und da kennt sich UlfZibis besser aus als ich.

• Als nächstes möchte ich mich mit dem mir rätselhaften Zusammenspiel von simulierten (transienten) und echten (persistenten) Dateirechten befassen.

• Ein weiteres, schwieriges Thema ist der (bzw. sind die) Zeitstempel. Gibt es sonstige Probleme mit Backup-Programmen (rsync, FreeFileSync) ?

• Auch sehr interessant für Dual Boot Systeme ist der Umgang mit (versehentlichem) Hibernate. Gibt es einen Schutz für die Windows-Systempartition wie bei NTFS-3G?

Auf einem ganz anderen Blatt steht die Frage, wer, wie, wann, wo mit NTFS3 Partitionen einbinden kann bzw. darf. Doch dafür ist ja schon viel Vorarbeit geleistet.

Schließlich ist die Frage der Wartung des Systems wichtig. Da gibt es derzeit nur die in NTFS-3G integrierten ntfsprogs. Kann man diese auch installieren bzw. verwenden, ohne das ganze NTFS-3G zu instellieren?