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?