Sparesbundles sich wieder unter den genannten Verzeichnissen einhängen lassen

Ich denke, ich habe die Lösung selbst gefunden:

$ ls -als@e ~/Pic*

total 0

0 drwx------ 2 me staff 68 29 Jun 18:44 .

0 drwxr-xr-x@ 77 me staff 2618 29 Jun 19:01 ..

com.apple.FinderInfo 32

0: group:everyone deny delete

$ chmod -a group:"everyone deny delete" ~/Pictures/..

$ hdiutil attach ~/Documents/Pictures.sparsebundle -mountpoint ~/Pictures -nobrowse

Ursache war obiges acl

Mit ~/Movies und ~/Music/iTunes klappt jene Methode unter Monterey problemlos und die Images mounten auch nach Doppelklick problemlos unter /Volumes.

Jenes Problem betrifft mW. nur ~/Pictures, da ~/Pictures/P funktioniert.

Die Ursache jenes Problems scheint zu sein, dass irgend ein Prozess unter Monterey jenen Ordner nach dessen Löschung durch rm -r ~/Pictures/ erneut anlegt und mit Inhalten füllt.

Vermutlich ist eine "Race-Condition" die Ursache jener Probleme, denn der Ordner lässt sich problemlos via rm -r ~/Pictures/ löschen.

Folgende Änderung des LaunchAgents ist unverzichtbar:

"/Users/myUser/Documents/Pictures.sparsebundle -mountpoint /Users/myUser/Pictures" muss in "~/Documents/Pictures.sparsebundle -mountpoint ~/Pictures" abgeändert werden.

Biker17 schrieb:

Die Frage ist doch sehr speziell -

Ja...

Ich bin schon sehr lange unter Unix/macOS aktiv und beantworte in Foren idR. ähnliche Fragen.

An jenem Problem bin ich jedoch gescheitert.

Meine aktuelle Arbeitsthese ist, dass ein Prozess unter macOS Monterey jenen Ordner immer wieder mit Daten füllt, weshalb der Launch-Agent keinen leeren Ordner vorfindet und deshalb scheitern muss.

Was in dem Ordner ist, kann ich auch mit ls -als ~/Pictures sehen.

Zusätzlich habe ich beim Admin-User "defaults write com.apple.Finder AppleShowAllFiles true" aktiv, d.h.:
Gebe ich dem Admin-User Lese- und Schreibrechte auf /Users/me/Pictures, sehe ich auch versteckte Dateien.

Das ist nicht das Problem.

Natürlich könnte ich ein "rm -r ~/Pictures" unmittelbar vor
"hdiutil attach ~/Documents/Pictures.sparsebundle -mountpoint ~/Pictures -nobrowse"

ausführen lassen, aber solch eine Methode hat ziemlich viel Katastrophenpotential.

Das Ganze ist vermutlich weniger ein Unix-Problem, als der Grund dafür, warum Apple ~/Pictures nicht via Finder löschen lässt.