Ich habe vor Kurzem eine Neuinstallation von Windows 10 auf einer neuen SSD durchgeführt und meine alten Datendateien auf dem Laufwerk wiederhergestellt. Das Problem ist, dass die Berechtigungen, obwohl ich dem Sicherungsprogramm gesagt habe, sie NICHT wiederherzustellen, am Ende trotzdem durcheinander geraten sind.
Ich habe bereits ausgeführttakeown /f c:\src /r /d Y
Ich habe versucht, in die Eigenschaften des Explorers -> Sicherheit zu gehen, habe meinen Benutzer mit der Berechtigung „VOLLE KONTROLLE“ zum Ordner hinzugefügt und ihn auf die untergeordneten Elemente angewendet. Windows lief angeblich eine halbe Stunde lang, aber Attribute: „Nur lesen“ war IMMER NOCH mit einem Kästchen ausgefüllt.
Ich habe das Feld „Nur lesen“ gelöscht, es rekursiv angewendet, Windows lief weitere 15–20 Minuten … und das verdammte Feld ist IMMER NOCH ausgefüllt.
Ich glaube, ich muss ICACLS verwenden ... aber ich habe Angst, es ohne Anleitung zu tun. Jedes Mal, wenn ich ICACLS in der Vergangenheit verwendet habe, um eine solche Situation zu beheben, hat es das Problem nur noch schlimmer gemacht. Ich verstehe Unix-artige Berechtigungen und Eigentumsverhältnisse sehr gut, aber NTFS-Berechtigungen haben mich jedes Mal geschlagen, wenn ich den Fehler gemacht habe, mich mit ihnen herumzuschlagen.
In der Vergangenheit habe ich meinen herkömmlichen Workaround verwendet, um das Problem mit roher Gewalt zu beheben: Linux booten, das Verzeichnis rekursiv (unter Beibehaltung der Zeitstempel) auf ein FAT32-Volume kopieren, Windows wieder booten, das Originalverzeichnis vom NTFS-Volume löschen und es dann vom FAT32-Volume zurückkopieren, wobei die NTFS-Berechtigungen gelöscht werden. Das kann ich jetzt nicht mehr tun ... das Verzeichnis enthält zu viele Dateien mit über 4 GB.
Also ... wie kann ich etwas Vergleichbares erreichen (vermutlich mit ICACLS)?
Lösung:
Basierend auf der Antwort unten haben wir Folgendes herausgefunden:
icacls c:\src /reset /T /L /Q
takeown /f c:\src /r /d Y(Ich habe takeown nach icacls erneut ausgeführt, nur für den Fall)
attrib -r -h -s c:\src /s /d
Es stellt sich heraus, gemäßDiese Antwort, dies ist nur ein Fall von Windows Explorer mit einem außerordentlich schlechten UI-Design. Einfach ausgedrückt wird Windows NIEMALS melden, dass der Inhalt eines Ordners „nicht schreibgeschützt“ ist. Sie können das Kontrollkästchen verwenden, um zu versuchen, den schreibgeschützten Status der im Ordner enthaltenen Dateien zu löschen oder festzulegen, aber der Status des Kontrollkästchens selbst gibt keinen sinnvollen Aufschluss über ihren aktuellen Status.
Microsofts Begründung ist offenbar, dass jeder Explorer-Ordner eine versteckte Systemdatei enthält, die aus Sicht eines Benutzers schreibgeschützt ist (und wenn die Datei nicht vorhanden ist, tut der Explorer so, als ob sie vorhanden wäre). Daher enthält jeder Ordner mindestens eine schreibgeschützte Datei, auch wenn keine der vom Benutzer absichtlich dort abgelegten Dateien schreibgeschützt sind. Seufz.
Wie auch immer, mein Problem ist jetzt behoben. Gradle und Android Studio können die Dateien erstellen, ohne aufgrund eines Berechtigungsfehlers abzustürzen. Das Zurücksetzen der ACLs, die Übernahme des Besitzes und das Löschen der Nur-Lese- und Systemflags (falls sie überhaupt vorhanden waren) löste das Problem.
Antwort1
"Attribute: [✔] Nur Lesen" ist kein NTFS-Berechtigungsflag. Es handelt sich um einen völlig separaten Satz von Dateiflags – oft als "MS-DOS-Attribute" bezeichnet. (Vergleiche Linux chattr.)
Dieses Attribut hat seinen Ursprung, ebenso wie „Versteckt“, „System“ und „Archiv“, im DOS-FAT-Dateisystem, Sie werden es also nicht los, wenn Sie Dateien auf ein FAT32-Volume und zurück kopieren.
Um sie rekursiv zu entfernen,
Sie müssen über die Berechtigung „Attribute schreiben“ für diese Dateien und Ordner verfügen.
attrib -r -h -s c:\src /s /d
system.ntfs_attrib_beAuf diese Attribute kann unter Linux beispielsweise als xattr zugegriffen werden :
setfattr -n system.ntfs_attrib_be -h -v 0x00000020 <filename>