ich suche zweielerlei:
a) nach dem Namen eines Konzepts - ich gehe davon aus, dass der Anwendungsfall so häufig ist, dass dieses Konzept einen Namen hat und
b) ob und wie sich das (unter Windows) realisieren lässt.
Ich habe einen Ordner z.B. D:\OrdnerA mit Unterordnern und Dateien, les- und schreibbar.
Ich will einen zweiten Ordner, einen anderen Pfad, z.B. C:\OrdnerB, der auf den gleichen Inhalt wie der erste Ordner abbildet, allerdings schreibgeschützt.
Wenn ein Programm in D:\OrdnerA\ schreibt, soll die Datei normal änderbar sein (und natürlich in C:\OrdnerB\ auch transparent geändert), wenn ein Programm in C:\OrdnerB\ zu schreiben versucht, soll dies wegen Schreibschutz verwehrt werden.
Sozusagen "Kiosk-Modus" für Ordner. Wie mag soetwas heißen?
Ich bin sicher, das es soetwas irgendwie gibt. Die gleichen Daten verschiedenen Nutzern nur-lesbar oder Vollzugriff zu gewähren ist ja Standard. Nur gleicher Nutzer bei unterschiedlichen Pfaden hatte ich bislang noch nicht.
symlink mit unterschiedlichen Leserechten, so könnte man unter Unix u.ä. andenken. Wenn das mit den getrennten Rechten so nicht geht, vielleicht über named pipe,
Oder man hat zwei mountpoints, auch für gemountede Device kann Rechte (über das gesamte fs) vergeben.
Unter Windows mit seinen löchrigen Rechtedomains würde ich sowas erst garnicht versuchen.
Du hast also ein Problem, für das Du Dir eine Lösung ausgedacht hast und jetzt suchst Du nach einer Möglichkeit, diese Lösung umzusetzen.
Das ist möglicherweise ein schwieriger Ansatz, weil vielleicht schon Deine Lösung Mist und Dein Problem mit einem anderen Ansatz viel besser (für eine beliebige Interpretation des Wortes "besser") umgesetzt werden könnte.
Deswegen ist es wahrscheinlich sinnvoller, wenn Du zunächst einen Schritt zurücktrittst und uns erst einmal das Problem beschreibst, das Du lösen möchtest.
Der Schritt zurück sagt: Ich habe einen mittelgroßen (ca. 30 GB) Haufen Daten, auf den buggy Programm "A" nur lesend und alle anderen braven Programme lesend und schreibend zugreifen dürfen sollen.
Statt einem Laufwerkbuchstaben kann man mit mklink auch einen Symlink / Directory Junction auf den Netzwerkpfad erstellen. Oder was auch immer diese Reparse Points unter Windows sind.
Man könnte das so machen: Download-OrdnerRW auf eine CD brennen. Und wenn sich was merkwürdiges im Download-OrderRW Verändert, eine neue CD brennen.
Oder noch anders: Schreibgeschützten USB-Stick in den Rechner stecken, den Download-OrderRW rüberkopieren - geht aber nicht - und dann über die "Scheiß-Technik" fluchen. Früher konnte man aber per Batch-Datei an den Lese-und Scheibeinstellungen herumfummeln. War technisch gesehen das A und O bei so manchen Sachen.
In Anbetracht der Tatsache, dass ich schon Leute kennengelernt haben, die im Großraumbüro regelmäßig erst laut furzen und dann laut lachen, ist diese Antwort natürlich absolut verständlich.
Leider nein. Die App läuft auf dem "Windows Subsystem für Android" (WSA), das immer im
Kontext des aktuellen Benutzers läuft.
"Wieviel" "AndroidApp" bringt den dieses Subsystem mit?
Android bietet doch die Möglichkeiten, einzelnen Apps die Schreibrechte zu entziehen (bzw. garnicht erst zuzuteilen). Damit dürfte der Wunsch nach "Schreib-Sicherung dediziert für buggy Programm A" auch erfüllbar sein.
(mklink funktioniert übrigens nur in der Konsole, nicht in der Powershell.)
Greife ich auf den Ordner "AndroidShare" im Benutzerprofil zu, habe ich den gewünschten Nur-Lese-Zugriff, den ich unter dem Windows-Subsystem für Android (WSA) teilen kann.
Leider funktioniert mein eigentliches Ziel damit nicht. Die Android-App (F-Stop Media Gallery) funktioniert nicht richtig, wenn WSA keine temporären Dateien im Bilder-Ordner anlegen kann. Was auch wohl mein ursprüngliches Problem war: Die WSA erzeugt ständig temporäre Dateien, der Schreibzugriff von WSA ist buggy (https://github.com/microsoft/WSA/issues/598), und damit wird im Handumdrehen der Inhalt meines Bilder-Ordners zerstört, weil ständig Metadaten geschrieben werden.
(Ärgerlich, aber nicht katastrophal, da alle Backups hinreichend frisch sind.)
Das scheint ein generelles Problem von WSA zu sein - Ich kann noch nicht einmal eine Datei vom Schreibgeschützten Verzeichnis in ein anderes kopieren zu können.
Danke für die hilfreichen Beiträge von Helmut und Daniel und den immerhin beim Thema bleibenden Beitrag von Jens!
Die WSA erzeugt ständig temporäre Dateien, der Schreibzugriff von WSA ist buggy
(https://github.com/microsoft/WSA/issues/598), und damit wird im Handumdrehen der Inhalt
meines Bilder-Ordners zerstört,
Also unter dem gegebenen bugreport wird ein etwas anderes Fehlerbild beschrieben. Da steht explizit das es keine dauerhafte Schädigung des Filesystems gibt, im Gegenteil es werden keine Daten in den shared ordner geschrieben, (obwohl das nötig wäre). OK der verlinkte Bugreport ist nicht ganz widerspruchsfrei, aber anders als hier im thread dargestellt.
Auszug aus der verlinkten Fehlerbeschreibung:
"There is no permanent corruption. It seems like memory corruption happens or there is some bug in the "share user folder" in tracking the files.
...
The files are not being written to either side(windows or WSA). This seems to be an internal bug with the implementation of "share user folder".
The issue, though, is persistent in that it will continue to report incorrect info.
...
Again, it seems to be something solely connected to the Share user folder.
..."
Also wenn ich recht verstehe, wird nicht der Inhalt sondern die "Info beschädigt". Da sollte man doch das OS dazu bringen, diese INFO neu tu generieren.
Wenn das Problem im "Android" liegt und nicht in der App: Versuch einen anderen Android-Emulator (WSA ist ja auch schon lange aus dem Support!), z.B. BlueStacks, oder gleich ein echtes Android-Gerät.
Zu dem kannst du mittels Syncthing einen Ordner identischen Inhalts mit nur begrenzter Synchronisierung machen und dann kann Android schreiben, zerfaselt aber nicht die Originale.
Also unter dem gegebenen bugreport wird ein etwas anderes Fehlerbild
beschrieben.
Ich weiß nicht genau, was passiert ist. Ich weiß nur genau, dass ich definitiv nicht will, dass das jemals wieder passiert. Die Kombination aus F-Stop Media Gallery und WSA ist durch meinen Bilder-Ordner gepflügt und hat etliche JPG-Bilder zerstört. Unter Android läuft es seit Jahren einwandfrei.
Bildersammlungen sind halt etwas, was man quasi "ewig" aufbewahren will und wo Fehler aber auch jahrelang unentdeckt bleiben können.
Versuch einen anderen Android-Emulator (WSA ist ja auch schon lange aus
dem Support!)
Mit WSAbuild wird WSA glücklicherweise außerhalb von Microsoft (naja, immer noch GitHub...) fortgeführt. Das ist auch gut so - denn es ist meines Erachtens der am wenigsten schlechte Android-Emulator.
BlueStacks kostet 8 US$/Monat und ist auch - zumindest für die Fotosammlung - deutlich zäher als WSA. Vielleicht taugt es für Spiele - das kann ich nicht beurteilen.
Ich habe es jetzt so gelöst, dass Android auf eine echte Kopie zugreift, die regelmäßig mit rsync aktualisiert wird. Nicht perfekt, aber gut genug. So muss ich nicht mehr mein Android-Tablet neben dem Windows-konvertible mitschleppen. (Lieber ein paar GB geopfert als 930 Gramm extra mitschleppen.)
WSA müsste doch eigentlich auf der selben Technologie basieren wie die WSL2, als eine VM. Android nutz einen vom linux Kernel abgeleiteten Kernel. Theoretisch müsste man in der WSA also bind mounts und overlays verwenden können. Dann könnte man theoretisch die Bilder Ordner in der WSA readonly mounten, und dann einen Overlay mount darüber setzen, mit einem leeren tmpfs oder so als Schreiboverlay, aber dem Bilderordner als darunterliegendes layer. Aus Anwendungssicht kann dann normal darauf geschrieben werden, aber nichts davon ändert irgend was an deinem Bilderordner.
Wie man das in der Praxis machen kann, weiss ich aber gerade auch nicht.
Besorg dir doch einfach mal einen gebrauchen Windows-Rechner oder einen kaputten, den du leicht reparieren kannst.
Darüberhinaus auch noch einen, wo du FreeDOS drauf installieren kannst. Sterben wirst du daran nicht - aber gewisse "Theorien" könnten damit gut abgebaut werden ;)
