ubuntuusers.de

Die Aussage "Die Option windows_names verdient besondere Beachtung. Sie sorgt dafür, dass Dateinamen unter Linux wie unter Windows üblich behandelt werden, insbesondere bzgl. Groß-/Kleinbuchstaben" ist wohl nicht richtig.

Auch mit der Option windows_names werden bei mir die Dateien XYZ und xyz unterschieden. Es ist auch möglich, XYZ nach xyz umzubenennen oder zu kopieren. Die Option windows_names betrifft ausschließlich die Zeichen, die in Windows nicht erlaubt sind, nicht aber die Unterscheidung von Groß- und Kleinbuchstaben.

Auch mit der Option windows_names verhält sich NTFS3 hier toleranter als z.B. exFAT.

Wenn keine Widersprüche erfolgen, werde ich dies im Artikel noch ändern.

Max-Ulrich_Farber schrieb:

Die Aussage "Die Option windows_names verdient besondere Beachtung. Sie sorgt dafür, dass Dateinamen unter Linux wie unter Windows üblich behandelt werden, insbesondere bzgl. Groß-/Kleinbuchstaben" ist wohl nicht richtig.

Du hast völlig recht. Bei ntfs3 ändert die Option windows_names nur die Behandlung von Sonderzeichen und den Umgang mit reservierten Dateinamen wie z.B. com1, aber wirkt sich nicht auf Groß-/Kleinschreibung aus.

In der Tabelle ist es wohl richtig beschrieben.

Ich habe außerdem noch den Abschnitt "Probleme und Lösungen / System bootet nach Absturz nicht mehr" angefügt. Denn ich bin selbst, obwohl ich diese Tücke von NTFS3 gut kannte, prompt in die Falle getappt! Ich las Logfiles, bastelte aufgeregt an GRUB und weiß Gott was herum und hängte mich sogar ans Telefon, weil mein System mit einer obskuren Fehlermeldung nicht mehr bootete. Ich kam nicht auf die naheliegende Idee, dass es nur an NTFS3 lag! Man denkt halt immer erst viel zu kompliziert… 😳

Der Satz

Nach reinen Veränderungen des Dateiinhalts (z.B. Schreiben in eine Textdatei) werden die Dateirechte jedoch nicht persistent.

stimmt nur eingeschränkt.

Einige Editoren, evtl. auch andere Programme, insbesondere GUI-Programme wie Gedit, schreiben eine neue Datei unter gleichem Namen, statt die alte zu verändern. Diese neue Datei hat dann auch neue persistente Rechte unter NTFS3. Die alte Datei wird entweder gelöscht oder umbenannt.
Unter NTFS-3G kommt dieser Umstand u.a. im Zusammenhang mit der Option inherit zum Tragen.

Das hat dann aber nichts mit dem Dateisystem zu tun, sondern mit den genutzten Programm. Somit nichts in diesem Artikel verloren.

Dass ein System mit z.B. durch Absturz beschädigten Dateisystem nicht mehr bootet, hat aber erst recht nicht speziell mit NTFS3 zu tun.

Das stimmt ja auch nicht, das System bootet natürlich, es startet nur nicht bis zur Benutzeroberfläche, wenn das NTFS über die fstab eingetragen ist und nicht eingunden werden kann.

Und das liegt dann sehr wohl an NTFS, da dafür kein fsck gemacht werden kann.

tomtomtom schrieb:

Das stimmt ja auch nicht, das System bootet natürlich, ...

Dann ist da aber ein Fehler im Artikel, denn da steht "bootet nicht". Und ansonsten dürfte auch ohne diese Spitzfindigkeit wohl klar sein, wovon wir hier sprechen.

Und das liegt dann sehr wohl an NTFS, da dafür kein fsck gemacht werden kann.

Alternativ könnte aber ntfsfix bemüht werden. Und außerdem, wenn fsck nicht erfolgreich ist, passiert das gleiche Problem auch mit EXT4. Somit ist das Problem wieder Dateisystem-unabhängig.

Dass ein Editor die neue Datei mit ggfs. anderen Rechten wieder neu schreibt, ist, soweit ich das überblicke, ein spezieller Effekt, der nur bei NTFS auftritt.

UlfZibis schrieb:

Der Satz

Nach reinen Veränderungen des Dateiinhalts (z.B. Schreiben in eine Textdatei) werden die Dateirechte jedoch nicht persistent.

stimmt nur eingeschränkt.

Nach meinen Experimenten stimmt der Satz sehr wohl genau so, wie er im Artikel steht.

Das was Du mit

Einige Editoren, evtl. auch andere Programme, insbesondere GUI-Programme wie Gedit, schreiben eine neue Datei unter gleichem Namen, statt die alte zu verändern. Diese neue Datei hat dann auch neue persistente Rechte unter NTFS3. Die alte Datei wird entweder gelöscht oder umbenannt.

beschreibst, ist ja kein reines Schreiben des Dateiinhalts, sondern es erfolgen durch die von Dir genannten (und von mir markierten) Operationen zusätzlich Änderungen an den Verwaltungsdaten der Datei.

Unter NTFS-3G kommt dieser Umstand u.a. im Zusammenhang mit der Option inherit zum Tragen.

Da dieser Artikel gar nicht NTFS-3G behandelt, ist das hier irrelevant.

UlfZibis schrieb:

Dass ein System mit z.B. durch Absturz beschädigten Dateisystem nicht mehr bootet, hat aber erst recht nicht speziell mit NTFS3 zu tun.

Es ist grundsätzlich richtig, dass dieses Verhalten auch bei anderen Dateisystemen auftreten kann, weshalb der allgemeine Artikel fstab davor auch gleich zu Beginn eindringlich warnt.

Dennoch ist speziell im Artikel für NTFS3 dieser Hinweis sinnvoll und wichtig, weil:

• Dieser Umstand – defektes (inkonsistentes) Dateisystem – bei NTFS in der Praxis häufiger auftritt, weil unter Windows ein inkonsistentes Dateisystem in bestimmten Situationen ein normaler Betriebszustand ist.

• NTFS unter Linux generell nicht zuverlässig, und an dieser Stelle (Systemstart) gar nicht reparierbar ist.

• NTFS3 sich an dieser Stelle anders verhält als NTFS-3G.

Ich habe den betreffenden Abschnitt überarbeitet, um die Besonderheiten bei der Verwendung von NTFS3 beim Systemstart darzustellen.

kB schrieb:

Dennoch ist speziell im Artikel für NTFS3 dieser Hinweis sinnvoll und wichtig, weil: ...

Dieser Darstellung kann ich voll zustimmen.

Ich habe den betreffenden Abschnitt überarbeitet, ...

Da steht aber jetzt immer noch drin, "System bootet nicht mehr", was nach Ansicht von tomtomtom falsch ist.

Nun aber zu meiner Anmerkung. Wenn dieser für NTFS3 typische Sachverhalt, wie tomtomtom meint, nicht in diesen Artikel gehört, wo gehört er denn dann hin?

UlfZibis schrieb:

[…] Da steht aber jetzt immer noch drin, "System bootet nicht mehr", was nach Ansicht von tomtomtom falsch ist.

Ich weiß nicht, ob Du tomtomtom richtig verstehst, aber aus meiner Sicht ist es so wie es im Artikel steht schon richtig.

Wenn man es schon spitzfindig machen will, dann ist auch „System bootet“ etwas anderes als „Rechner bootet“:

• Im hier interessierenden Fall bootet der Rechner zweifellos, weil die Firmware des Rechners erfolgreich einen Bootmanager, z.B. GRUB gestartet hat und GRUB ebenso erfolgreich einen Linux-Kernel samt initrd.img geladen und gestartet hat.

• Jedoch während des nun anschließenden Vorgangs „Betriebssystem bootet“ kommt es ebenso zweifellos zu einem Fehler, weil ein als zwingend benötigt bezeichnetes Dateisystem eben nicht eingebunden werden kann und damit dieser Teil des Bootens in einer Kernel-Panik endet.

Aus Sicht des Anwenders wird er dieses Verhalten wohl als „System bootet nicht mehr“ beschreiben, weshalb genau diese Überschrift im Kapitel „Probleme und Lösungen“ auch angemessen, sinnvoll und passend ist. Ob sich der spitzfindige Fachmensch an diesem mehrdeutigen Wort „bootet“ mental verschluckt oder nicht, ist aus meiner Sicht irrelevant – jedenfalls für ein Wiki.

Und weil dieser Sachverhalt nun mal unter nicht unüblichen widrigen Umständen bei Verwendung von NTFS3 häufiger auftritt als sonst, gehört das auch in diesen Artikel über NTFS3, obwohl NTFS3 selbst daran unschuldig ist.

kB schrieb:

Aus Sicht des Anwenders wird er dieses Verhalten wohl als „System bootet nicht mehr“ beschreiben, weshalb genau diese Überschrift im Kapitel „Probleme und Lösungen“ auch angemessen, sinnvoll und passend ist. Ob sich der spitzfindige Fachmensch an diesem mehrdeutigen Wort „bootet“ mental verschluckt oder nicht, ist aus meiner Sicht irrelevant – jedenfalls für ein Wiki.

So sehe ich es auch. Die Kritik kam ja nicht von mir.

UlfZibis schrieb:

Nun aber zu meiner Anmerkung. Wenn dieser für NTFS typische Sachverhalt, wie tomtomtom meint, nicht in diesen Artikel gehört, wo gehört er denn dann hin?

Die Option nohidden versteckt nicht nur die mit H markierten Dateien, sondern auch alle Links außer Hardlinks. Wie weit dies nur echte SymLinks oder auch Junctions und Volume References betrifft, habe ich nicht untersucht.

Genaugenommen werden sie auch nicht nur versteckt, denn das würde ja bedeuten, dass man sie mit entsprechenden Optionen (von ls z.B.) sichtbar machen könnte und mit passenden Befehlen auch irgendwie öffnen und bearbeiten. Sie sind dann einfach nicht existent. Mittels ntfsinfo kann man aber zumindest deren Low-Level-Einträge finden.

Mit

sudo ntfsinfo -F /PFAD/ORDNERNAME/ -v /dev/sdXY 2>&1 | grep -e "EA length" -e "Filename:"

kann man auch feststellen, ob Dateien in einem Ordner schon unter NTFS3 verwaltet werden, oder deren Rechte nur simuliert werden.
... | grep -e "File attributes:" -e "Filename:" zeigt die Windows Attribute.
Beides fände ich eine sinnvolle Ergänzung für den Wiki-Artikel.

Da externe NTFS-Platten nun standardmäßig per NTFS3 eingebunden werden, kann man dadurch dann noch auf ein weiteres Problem stoßen.
Hat man nämlich (versehentlich) dort unter Root oder einem anderen Benutzer als 1000 Ordner oder Dateien angelegt, kann man diese dann z.B. an einen anderen Rechner "nicht normal" bearbeiten. Man muss dann alles unter Root machen.

Und Last but not Least fände ich es auch sinnvoll, an prominenter Stelle darauf hinzuweisen, dass NTFS3 im wesentlichen unbrauchbar für den Zugriff auf Windows-Benutzerordner ist.

UlfZibis schrieb:

Die Option nohidden versteckt nicht nur die mit H markierten Dateien, sondern auch alle Links außer Hardlinks. Wie weit dies nur echte SymLinks oder auch Junctions und Volume References betrifft, habe ich nicht untersucht.

Mit anderen Worten:

• Ohne gesetzte Option nohidden werden unter Linux einige unter Windows unsichtbare Dateien angezeigt. Dies betrifft Dateien mit dem Attribut HIDDEN und Links außer Hardlinks.

• Mit gesetzter Option nohidden zeigt Linux die Dateien wie von Windows gewohnt an.

Genaugenommen werden sie auch nicht nur versteckt, denn das würde ja bedeuten, dass man sie mit entsprechenden Optionen (von ls z.B.) sichtbar machen könnte und mit passenden Befehlen auch irgendwie öffnen und bearbeiten. Sie sind dann einfach nicht existent. Mittels ntfsinfo kann man aber zumindest deren Low-Level-Einträge finden.

Das verstehe ich jetzt nicht. So weit ich mich erinnere, kann man unter Windows mit versteckten Dateien ganz normal arbeiten, sobald man deren geheim gehaltenen Namen kennt. Linux sollte sich genauso verhalten.

[…] ntfsinfo […]

ntfsinfo stammt aus welchem Paket?

Beides fände ich eine sinnvolle Ergänzung für den Wiki-Artikel.

Beides sind sinnvolle Ansätze, aber noch ein wenig unscharf verstanden. Da benötige ich noch einige Untersuchungen.

Da externe NTFS-Platten nun standardmäßig per NTFS3 eingebunden werden, kann man dadurch dann noch auf ein weiteres Problem stoßen.
Hat man nämlich (versehentlich) dort unter Root oder einem anderen Benutzer als 1000 Ordner oder Dateien angelegt, kann man diese dann z.B. an einen anderen Rechner "nicht normal" bearbeiten. Man muss dann alles unter Root machen.

Das verstehe ich auch nicht. Unter Windows wie unter Linux werden die Dateien eines Besitzers vor dem Zugriff durch andere Benutzer geschützt. Die verwendeten Methoden unterscheiden sich zwar, aber im Schutzziel ist man sich einig. Das ist also ein ganz normales, erwünschtes und erwartetes Verhalten.

Und Last but not Least fände ich es auch sinnvoll, an prominenter Stelle darauf hinzuweisen, dass NTFS3 im wesentlichen unbrauchbar für den Zugriff auf Windows-Benutzerordner ist.

Davon bin ich noch nicht überzeugt. Ich erwarte, dass Dateien vor dem Zugriff Fremder geschützt werden. ntfs3 verhält sich hier total richtig. Ich bin lediglich Überrascht, dass dieses Attribut READONLY so weit verbreitet ist. Es hat schließlich mit der Rechteverwaltung unter Windows nichts zu tun, sondern stammt aus Zeiten, als CP/M Technologieführer war. Davon hat DOS es geklaut und bisher war ich der Meinung, dass Windows es nur aus Kompatibilitätsgründen noch kennt.