staging.inyokaproject.org

kB schrieb:

Mit anderen Worten:

• Ohne gesetzte Option nohidden werden unter Linux einige unter Windows unsichtbare Dateien angezeigt.

Ich würde sie eher "normalerweise versteckte" nennen. Sichtbar werden sie ja mit bestimmten Einstellungen, und das ist auch die exakte Übersetzung von "hidden".

Dies betrifft Dateien mit dem Attribut HIDDEN und Links außer Hardlinks.

"Dies" bezieht sich auf "werden angezeigt". Also betrifft es sie eben genau negiert. Deshalb:

• In Windows werden Dateien mit dem Attribut HIDDEN und Links zu solchen unter normalen Einstellungen nicht angezeigt, also versteckt.

• Will man von Linux aus nur auf diese Zugriff erlauben, setzt man unter NTFS3 die Option nohidden.

• Ohne diese Option erlaubt NTFS3 Zugriff auf alle Dateien, also auch auf die in Windows versteckten.

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.

Genau das geht unter dieser Konstellation in Linux eben nicht. Linux kennt kein vergleichbares Hidden-Flag welches mit irgendeiner Option aufgehoben werden könnte. Lediglich zeigen Dateimanager und ls Dateien standardmäßig nicht an, wenn deren Namen mit einem Punkt beginnt.

ntfsinfo stammt aus welchem Paket?

ntfs-3g – steht doch sogar im Artikel, ist standardmäßig installiert.

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

Ja gerne, spiel' ein bisschen rum damit. Vielleicht fällt Dir auch noch eine schickere Befehlszeile ein. Schön wäre z.B. wenn der zugehörige Dateiname vor den Attributen käme, und am besten in einer Zeile.

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.

Soweit ich in Erinnerung habe, handhabt Windows das bei per USB angesteckten Medien anders. Man kann Dateien unter Benutzer A auf eine Backup-Platte kopieren, und die mit Benutzer B auf einem anderen Rechner wieder lesen und bearbeiten. Hab' leider keine 2 Windows-Rechner da, um das zu verifizieren. Mit NTFS-3G unter Linux ist das auch der Normalfall, mit NTFS3 hingegen nicht.

Die verwendeten Methoden unterscheiden sich zwar, aber im Schutzziel ist man sich einig. Das ist also ein ganz normales, erwünschtes und erwartetes Verhalten.

Unter Windows ist das meines Wissens bei externen Medien nur der Fall, wenn man beim Kopieren bestimmte Optionen verwendet. Man kann sie auf jeden Fall mit Admin-Rechten deaktivieren, unter NTFS3 geht noch nicht mal das.

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.

Dann verstehe ich nicht, warum bisher keiner auf meine Support-Frage einen Weg gezeigt hat, wie ich unter NTFS3 z.B. im Benutzerordner Pictures eine Datei hinzufügen kann (außer mit der Brechstange von sudo).

Ich erwarte, dass Dateien vor dem Zugriff Fremder geschützt werden.

Das kommt auf die Art des Zugriffs an. Ordner Löschen oder Umbenennen ist ein anderer Zugriff, als eine neue Datei darin zu erstellen. Das w-Recht in Linux erlaubt oder verbietet beides auf einmal.

ntfs3 verhält sich hier total richtig.

Da bin ich anderer Meinung. Das R-Atttribut eines Ordners verbietet unter Windows nicht, dass ich dort eine neue Datei drin erstellen kann. Das durch NTFS3 entzogene w-Recht leider schon. Das R-Attribut sollte deshalb in das Immutable-Flag transformiert werden, und nicht das w-Recht entziehen. Und konsequenterweise sollte das absichtliche Löschen des Immutable-Flags – unter Root – dazu führen, dass das R-Attribut dann auch gelöscht wird.

Ich bin lediglich Überrascht, dass dieses Attribut READONLY so weit verbreitet ist.

Ich auch, deshalb ja meine bisher ungelöste Support-Frage.

Es hat schließlich mit der Rechteverwaltung unter Windows nichts zu tun,

Oh doch, siehe oben. Auch das S-Attribut (=System) hat noch Bedeutung. Eine Datei mit diesem kann man nicht einfach so mit DELETE löschen. Vorher muss man das S-Attribut mittels ATTRIB entfernen.

... dass Windows es nur aus Kompatibilitätsgründen noch kennt.

Nicht nur kennt, sondern auch berücksichtigt. Backup-Programme unter Windows berücksichtigen auch immer noch das A-Attribut (=Archiv).

Überraschung:

praxis@T540p:~$ stat /mnt/Daten/Users/Praxis/Pictures
  Datei: /mnt/Daten/Users/Praxis/Pictures
 Größe: 0         	Blöcke: 0          EA Block: 4096   Verzeichnis
Gerät: 8/7	Inode: 52          Verknüpfungen: 1
Zugriff: (0555/dr-xr-xr-x)  Uid: ( 1000/  praxis)   Gid: ( 1000/  praxis)
Zugriff: 2025-07-14 13:53:56.318546800 +0200
Modifiziert: 2025-07-09 00:40:47.165337600 +0200
Geändert: 2025-07-09 00:40:47.165337600 +0200
Geburt: 2025-07-09 00:39:08.490528800 +0200
praxis@T540p:~$ stat /mnt/Daten/Users/Praxis/AppData
  Datei: /mnt/Daten/Users/Praxis/AppData
 Größe: 0         	Blöcke: 0          EA Block: 4096   Verzeichnis
Gerät: 8/7	Inode: 59          Verknüpfungen: 1
Zugriff: (0775/drwxrwxr-x)  Uid: ( 1000/  praxis)   Gid: ( 1000/  praxis)
Zugriff: 2025-07-14 14:06:47.831252300 +0200
Modifiziert: 2025-07-09 00:39:08.959242000 +0200
Geändert: 2025-07-09 00:39:08.959242000 +0200
Geburt: 2025-07-09 00:39:08.490528800 +0200

stat zeigt keinen Unterschied in den Eigenschaften für die beiden Dateien.

ls -al listet den Ordner AppData aber nicht (hat das H-Attribut). Was ist das denn für eine verquere Logik?

praxis@T540p:~$ ls -al /mnt/Daten/Users/Praxis/
insgesamt 16
drwxrwxr-x 1 praxis praxis 8192 Jul 14 13:55  .
drwxrwxr-x 1 praxis praxis    0 Jul  9 21:37  ..
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39 '3D Objects'
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Contacts
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Desktop
dr-xr-xr-x 1 praxis praxis 4096 Jul  9 00:39  Documents
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Downloads
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Favorites
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Links
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Music
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:41  OneDrive
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:40  Pictures
drwxrwxr-x 1 praxis praxis    0 Mär  5 13:42  Roaming
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39 'Saved Games'
dr-xr-xr-x 1 praxis praxis 4096 Jul  9 00:40  Searches
drwxrwxr-x 1 praxis praxis    0 Jul 14 13:55  Test1
dr-xr-xr-x 1 praxis praxis    0 Jul 14 13:55  Test2
drwxrwxr-x 1 praxis praxis    0 Jul 14 13:55  Test4
dr-xr-xr-x 1 praxis praxis    0 Jul 14 13:55  Test6
dr-xr-xr-x 1 praxis praxis    0 Jul 13 19:25  Videos

Wenn ich im grafischen Dateimanager in den Ordner /mnt/Daten/Users/Praxis/ gehe, und dort die Suchfunktion bemühe, wird AppData allerdings nicht gefunden. find findet die Datei auch nicht:

$ find /mnt/Daten/Users/Praxis/ -name AppData

Mit der Option -d geht's aber dann doch, obwohl die mit Verstecken nix zu tun hat:

$ ls -ald /mnt/Daten/Users/Praxis/AppData
drwxrwxr-x 1 praxis praxis 0 Jul  9 00:39 /mnt/Daten/Users/Praxis/AppData

UlfZibis schrieb:

[…] handhabt Windows das bei per USB angesteckten Medien anders

Ist ein ganz anderer Anwendungsfall mit anderen Randbedienungen. Wir verzetteln uns, wenn wir dem folgen würden. Ich ignoriere das also jetzt.

Dann verstehe ich nicht, warum bisher keiner auf meine Support-Frage einen Weg gezeigt hat, wie ich unter NTFS3 z.B. im Benutzerordner Pictures eine Datei hinzufügen kann (außer mit der Brechstange von sudo).

Ich habe Dir im Support-Thread einen Weg vorgeschlagen: Entferne das Bit READONLY. Leider geht das wohl nur unter Windows.

DU willst meinem Vorschlag nicht folgen. Ok, aber jammere nicht, dass man Dir nicht geholfen hätte.

[…] Ordner Löschen oder Umbenennen ist ein anderer Zugriff, als eine neue Datei darin zu erstellen. Das w-Recht in Linux erlaubt oder verbietet beides auf einmal.

• Einen Ordner anzulegen, löschen oder umzubenennen sind unter Linux Schreibzugriffe auf den übergeordneten Order „..“.

• In einem Order „.“ eine Datei anzulegen, zu löschen oder umzubenennen sind Schreibzugriffe auf den Ordner „.“ selbst.

• Eine Datei in einem Ordner inhaltlich zu verändern, ist ein Schreibzugriff auf die Datei selbst.

Jeder der 3 Fälle wird zwar über das w-Recht kontrolliert, aber es handelt sich um das w-Recht bei 3 verschiedenen Dateien und ist daher einzeln unter Linux konfigurierbar, genauso wie unter Windows das Bit READONLY auch an den 3 verschiedenen Dateien unterschiedlich gesetzt werden könnte.

[…] Das R-Atttribut eines Ordners verbietet unter Windows nicht, dass ich dort eine neue Datei drin erstellen kann.

Möglich, das es so ist, aber da bin ich mir nicht sicher. Bist Du sicher, dass es wirklich zutrifft?

Das durch NTFS3 entzogene w-Recht leider schon.

Ja. Aber ist das unter Windows wirklich anders?

Das R-Attribut sollte deshalb in das Immutable-Flag transformiert werden, und nicht das w-Recht entziehen. Und konsequenterweise sollte das absichtliche Löschen des Immutable-Flags – unter Root – dazu führen, dass das R-Attribut dann auch gelöscht wird.

Es mag sein, dass hier eine Design-Schwäche im Modul ntfs3 aufgezeigt wurde. Ich bin noch nicht überzeugt, sehe aber, dass weitere Studien hier sinnvoll wären.

Deinen Verbesserungsvorschlag sehe ich vorläufig kritisch, weil ich nicht sicher bin, ob Dein Vorschlag wirklich ein besseres Verhalten ergibt als die bisherige Implementierung. Deshalb will ich das auch an dieser Stelle nicht weiter diskutieren; Du magst das an anderer Stelle mit den Kernel Entwicklern tun.

Mein Ansatz wäre, die Beachtung des READONLY abschaltbar zu machen, ähnlich wie HIDDEN.

[…] Rechteverwaltung unter Windows […] S-Attribut (=System) […] A-Attribut (=Archiv)

Diese Attribute zusammen mit READONLY und HIDDEN werden zwar von Windows beachtet und benutzt, haben aber mit der Rechteverwaltung von Windows nichts zu tun, sondern bilden die Rechteverwaltung des FAT-Dateisystems, welches bei IBMDOS und MS-DOS verwendet wurde. Es ist also ein unabhängiges drittes Berechtigungssystem in diesem Chaos neben den beiden inkompatiblen Berechtigungssystemen von Windows und Linux.

kB schrieb:

Ist ein ganz anderer Anwendungsfall mit anderen Randbedienungen. Wir verzetteln uns, wenn wir dem folgen würden. Ich ignoriere das also jetzt.

Genehmigt.
Eine Bemerkung erlaube ich mir aber dennoch: Das Weglassen eines solchen Hinweis bzgl. dieses Unterschieds zwischen dem gewohnten Verhalten von NTFS-3G und NTFS3 könnte mit der Zeit Supportanfragen wie "Ich kann nur noch unter Root auf mein Backup-Medium schreiben" zur Folge haben. NTFS3 ist ja noch nicht so verbreitet, weil bei Updates auf 24.04 ja NTFS-3G weiterverwendet wird.

Ich habe Dir im Support-Thread einen Weg vorgeschlagen: Entferne das Bit READONLY. Leider geht das wohl nur unter Windows.

Ein von-hinten-durch-die-Brust-ins-Auge-Weg, ja.

DU willst meinem Vorschlag nicht folgen. Ok, aber jammere nicht, dass man Dir nicht geholfen hätte.

Richtig, denn die Manipulation des Windows-Sicherheitskonzepts halte ich nicht für eine wirkliche Lösung, zumal der Trick mit der Zeit auch immer mal wieder versagen könnte, wenn irgend ein Update oder ein Windows-Aufräum-Tweak-Tool den "richtigen" Zustand wieder herstellt, oder unter Windows ein neuer so geschützter Ordner entsteht. Außerdem erfordert sie tiefere Windows-Kenntnisse, die man auch nicht überall voraussetzen kann – wer kann schon mit dem Windows-Terminal geübt umgehen? Der Schutz vor versehentlichem Löschen/Umbenennen eines der Standard-Windows-Benutzerordner ist so jedenfalls kaputt.

[…] Das R-Atttribut eines Ordners verbietet unter Windows nicht, dass ich dort eine neue Datei drin erstellen kann.

Möglich, das es so ist, aber da bin ich mir nicht sicher. Bist Du sicher, dass es wirklich zutrifft?

Da bin ich mir ganz sicher. Stell Dir vor, der Käufer eines Windows-Rechners will unter Dokumente seine erste Datei anlegen oder per Browser seine erste Datei nach Downloads speichern und dann kommt die Fehlermeldung "Keine Berechtigung". Ich möchte nicht der Verkäufer in dem Laden sein, wo ein solcher Rechner verkauft wurde.

Das durch NTFS3 entzogene w-Recht leider schon.

Ja. Aber ist das unter Windows wirklich anders?

Ja, siehe oben.

Das R-Attribut sollte deshalb in das Immutable-Flag transformiert werden, und nicht das w-Recht entziehen. Und konsequenterweise sollte das absichtliche Löschen des Immutable-Flags – unter Root – dazu führen, dass das R-Attribut dann auch gelöscht wird.

Es mag sein, dass hier eine Design-Schwäche im Modul ntfs3 aufgezeigt wurde. Ich bin noch nicht überzeugt, sehe aber, dass weitere Studien hier sinnvoll wären.

Deinen Verbesserungsvorschlag sehe ich vorläufig kritisch, weil ich nicht sicher bin, ob Dein Vorschlag wirklich ein besseres Verhalten ergibt als die bisherige Implementierung.

Ja, da gäbe es sicher einige Randbedingungen zu überprüfen, was hier nicht unsere Aufgabe ist.

Du magst das an anderer Stelle mit den Kernel Entwicklern tun.

Bin kurz davor, einen entsprechenden Launchpad-Bug auf die Reise zu schicken.

Mein Ansatz wäre, die Beachtung des READONLY abschaltbar zu machen, ähnlich wie HIDDEN.

Auch eine Möglichkeit, würde es dann aber einem Linux-Benutzer sehr leicht machen, so einen Ordner dann auch zu löschen oder umzubenennen, z.B. von Documents zu Dokumente, weil ihm das besser gefällt und Windows im Dateimanager ja auch nur die deutsche Übersetzung anzeigt. Irgendwann erstellt Windows den Documents-Ordner dann noch mal neu, und dann hat man 2 gleichlautende Ordner nebeneinander in Windows-Explorer. ... OK, ich hör' jetzt mal auf mit üblen "Horrorszenarien". 😉

[…] Rechteverwaltung unter Windows […] S-Attribut (=System) […] A-Attribut (=Archiv)

Diese Attribute zusammen mit READONLY und HIDDEN werden zwar von Windows beachtet und benutzt, haben aber mit der Rechteverwaltung von Windows nichts zu tun,

Das verstehe ich jetzt nicht. Wenn sie beachtet werden sind sie doch Bestandteil der Rechteverwaltung, weil sie eben Lösch/Umbenenn-Rechte einschränken können.

sondern bilden die Rechteverwaltung des FAT-Dateisystems, welches bei IBMDOS und MS-DOS verwendet wurde.

... und auch noch über Windows 3.11, 95, 98 bis Millenium.

Es ist also ein unabhängiges drittes Berechtigungssystem in diesem Chaos neben den beiden inkompatiblen Berechtigungssystemen von Windows und Linux.

Wenn wir noch Posix ACLs dazunehmen, sind es sogar 4 und mit dem wenig bekannten Immutable etc. Gedöns sogar 5.

Und dann reagieren stat, ls -al und find noch auf das intern wie auch immer gestaltete NTFS3-eigene Verstecksystem (was es unter Linux meines Wissens nicht gibt) inkonsistent. Oder kennst Du einen Befehl, mit dem man Dateien in Linux unsichtbar schalten kann?

kB schrieb:

... Ich erwarte, dass Dateien vor dem Zugriff Fremder geschützt werden. ntfs3 verhält sich hier total richtig. ...

Noch ein Gedanke dazu. Es gibt eine noch viel schwerwiegendere und nicht abstellbare Unterwanderung des Windows-Zugriffsschutzes durch NTFS3. Jede durch NTFS3 erstellte oder geänderte Datei hat unter Windows nämlich Vollzugriff für alle. Mit NTFS-3G lässt sich das zumindest mit Hilfe dem UserMapping sauber abstellen.

Und es kommt noch doller ... Graphische Editoren unter Linux haben die Eigenart, dass sie beim "Ändern" einer vorhandenen Datei beim Abspeichern den neuen Inhalt zunächst in eine temporäre Datei mit anderem Namen schreiben, dann das Original löschen und schließlich der neuen Datei den alten Namen verpassen. Auf diese Weise bekommt eine ursprünglich unter Windows mit einschränkenden Rechten versehene Datei dann Vollzugriff für Jedermann. Dieses Problem ist mir vor 10 oder mehr Jahren auch schon unter NTFS-3G aufgefallen, was dann durch meine Initiative die Einführung der Mount-Option inherit verursacht hat, um die Probleme damit zu mildern.

Bzgl. des Immutable-Flags habe ich mich leider geirrt, siehe 9480192

UlfZibis schrieb:

Und es kommt noch doller ... Graphische Editoren unter Linux haben die Eigenart, dass sie beim "Ändern" einer vorhandenen Datei beim Abspeichern den neuen Inhalt zunächst in eine temporäre Datei mit anderem Namen schreiben, dann das Original löschen und schließlich der neuen Datei den alten Namen verpassen. Auf diese Weise bekommt eine ursprünglich unter Windows mit einschränkenden Rechten versehene Datei dann Vollzugriff für Jedermann. Dieses Problem ist mir vor 10 oder mehr Jahren auch schon unter NTFS-3G aufgefallen, was dann durch meine Initiative die Einführung der Mount-Option inherit verursacht hat, um die Probleme damit zu mildern.

Im Artikel wird behauptet:

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

Das ist zwar technisch richtig, stimmt aber in der praktischen Anwendung aus gewöhnlicher User-Sicht nicht. Deshalb hatte ich das schon vor einem Jahr kritisiert.

Ein interessanter Vorschlag zum Thema: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1969085 🇬🇧

UlfZibis schrieb:

Ein interessanter Vorschlag zum Thema: […]

Ja. Nutzer von ntfs3 sollten diesen Vorschlag durch „Anheizen“ unterstützen.

UlfZibis schrieb:

[…] Im Artikel wird behauptet:

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

Das ist zwar technisch richtig, stimmt aber in der praktischen Anwendung aus gewöhnlicher User-Sicht nicht.

Du meinst vielleicht: Die technisch richtige Formulierung können Leute mit fehlendem Hintergrundwissen in manchen Situationen (GUI-Editor) irrtümlich als falsch erleben?

kB schrieb:

Du meinst vielleicht: Die technisch richtige Formulierung können Leute mit fehlendem Hintergrundwissen in manchen Situationen (GUI-Editor) irrtümlich als falsch erleben?

GENAU !!!

Deshalb finde ich, dass man dem Satz einen Hinweis verpassen sollte.

Ansonsten habe ich das Thema jetzt auch mal auf Launchpad "verewigt":

Adding files to Windows standard user folders is impossible with NTFS3 kernel driver

Da es ein sicherheitsrelevanter Bug ist, wird er vorerst nicht öffentlich sichtbar sein. Deshalb hier der Text:
(Wer da was ergänzen oder "anheizen" möchte, möge mit seine Lauchpad ID mitteilen, dann füge ich ihn zur subscriber liste.)

Windows standard user folders are flagged with attribute READONLY:
C:\Users>Attrib Praxis\* /D
     R               C:\Users\Praxis\3D Objects
                     C:\Users\Praxis\Anwendungsdaten
    H                C:\Users\Praxis\AppData
     R               C:\Users\Praxis\Contacts
   SH   I            C:\Users\Praxis\Cookies
     R               C:\Users\Praxis\Desktop
     R               C:\Users\Praxis\Documents
     R               C:\Users\Praxis\Downloads
        I            C:\Users\Praxis\Druckumgebung
     R               C:\Users\Praxis\Eigene Dateien
     R               C:\Users\Praxis\Favorites
     R               C:\Users\Praxis\Links
                     C:\Users\Praxis\Lokale Einstellungen
     R               C:\Users\Praxis\Music
        I            C:\Users\Praxis\Netzwerkumgebung
A   H   I            C:\Users\Praxis\NTUSER.DAT
A  SH                C:\Users\Praxis\ntuser.dat.LOG1
A  SH                C:\Users\Praxis\ntuser.dat.LOG2
A  SH                C:\Users\Praxis\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TM.blf
A  SH                C:\Users\Praxis\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000001.regtrans-ms
A  SH                C:\Users\Praxis\NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer00000000000000000002.regtrans-ms
   SH                C:\Users\Praxis\ntuser.ini
     R               C:\Users\Praxis\OneDrive
     R               C:\Users\Praxis\Pictures
     R               C:\Users\Praxis\Recent
                     C:\Users\Praxis\Roaming
     R               C:\Users\Praxis\Saved Games
     R               C:\Users\Praxis\Searches
     R  I            C:\Users\Praxis\SendTo
     R               C:\Users\Praxis\Startmenü
     R               C:\Users\Praxis\Videos
        I            C:\Users\Praxis\Vorlagen

The NTFS3 driver withdraws the write right from such files with the READONLY attribute:
$ ls -al /mnt/Daten/Users/Praxis/
insgesamt 16
drwxrwxr-x 1 praxis praxis 8192 Jul 13 15:51  .
drwxrwxr-x 1 praxis praxis    0 Jul  9 21:37  ..
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39 '3D Objects'
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Contacts
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Desktop
dr-xr-xr-x 1 praxis praxis 4096 Jul  9 00:39  Documents
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Downloads
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Favorites
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Links
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39  Music
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:41  OneDrive
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:40  Pictures
drwxrwxr-x 1 praxis praxis    0 Mär  5 13:42  Roaming
dr-xr-xr-x 1 praxis praxis    0 Jul  9 00:39 'Saved Games'
dr-xr-xr-x 1 praxis praxis 4096 Jul  9 00:40  Searches
dr-xr-xr-x 1 praxis praxis    0 Jul 13 19:25  Videos

The partition was statically mounted by /etc/fstab:
$ findmnt --type ntfs3
TARGET                 SOURCE    FSTYPE OPTIONS
/mnt/Daten             /dev/sda7 ntfs3  rw,relatime,uid=1000,gid=1000,dmask=0002,fmask=0113,discard,nohidden,hide_dot_files,windows_names,iocharset=utf8

I see no possibility to have drwxrwxr-x instead dr-xr-xr-x for e.g. folder "Documents". So it is impossible to add new files to such folders. Theoretically it's possible to remove the READONLY attributes from Windows side, but this would be a security risk for Windows.

On Windows, attribute READONLY does not prevent from adding files to such folders, it only prevents from renaming and deleting the folder itself, but the withdrawal of 'w' in Linux prevents from both. So the NTFS3 simulation of access rights is wrong here.

My suggestion:
With attribute R on a folder NTFS3 should only prevent from deleting and renaming somehow, maybe by simulating a suitable posix ACL, but enable 'w'.

Bearbeitet von kB:

Forensyntax (externer Link) korrigiert.

Ich fürchte, die Sprache dort ist nicht britisch, sondern US-amerikanisch 😉
Na wenn schon Syntax-Korrektur, warum nicht diese: 1969085 🇺🇸. Oder gar diese: Extract ntfsprogs package from ntfs-3g for ntfs3 kernel driver 🇺🇸.

UlfZibis schrieb:

Überraschung:

[.....]

stat zeigt keinen Unterschied in den Eigenschaften für die beiden Dateien.

Ich habe nun auch mal einen Fehlerbericht 🇺🇸 zu der mysteriösen nohidden-Thematik formuliert. Dafür die hoffentlich richtigen Worte zu finden, war nicht einfach.
Bin gespannt, ob und was daraus wird.

UlfZibis schrieb:

[…] mysteriösen nohidden-Thematik formuliert. Dafür die hoffentlich richtigen Worte zu finden, war nicht einfach.

Die Option nohidden ist einfach nur schlecht, eigentlich sogar falsch benannt. Bessere, weil das Verhalten besser beschreibende Namen wären no-unhidden oder no-show-hidden oder no-ignore-hidden.

Wenn man vom Anwender erwartet, dass er mittels doppelter Verneinung durch aktives Einschalten ein standardmäßiges Ignorieren eines bestimmten Verhalten (Ignorieren von Dateien) eines fremden Betriebssystems ausschaltet und dann auch noch den Schalter falsch beschriftet, sind Missverständnisse nahezu unvermeidbar. Oder einfacher: nohidden einschalten schaltet das Ignorieren der Ignorierung aus.

Eine einfache Lösung wäre also:

• Erkläre nohidden als deprecated (veraltet).

• Schaffe neue Option no-show-hidden mit der Funktionalität des veralteten nohidden.

kB schrieb:

Die Option nohidden ist einfach nur schlecht, eigentlich sogar falsch benannt.

Da kann man sicher drüber diskutieren.

Ich verstehe es so: Mounte/zeige (nur) nicht-versteckte Dateien, oder mounte/zeige versteckte Dateien nicht.

Die Amerikaner verwenden ja auch gerne "non-disclosed dokuments" oder "non-disclosed recipients" ... eine 3-fache Verneinung.

Auch noch ein interessanter Erweiterungsvorschlag: Add maintenence options for NTFS3 to ntfsprogs

Neue Entdeckungen, die für den Artikel interessant sein könnten:

1. 9481086

2. 9481088

UlfZibis schrieb:

Ansonsten habe ich das Thema jetzt auch mal auf Launchpad "verewigt":

Adding files to Windows standard user folders is impossible with NTFS3 kernel driver

Der Bug ist nach Prüfung nun öffentlich sichtbar.