Um auszuschließen, dass es sich um ein Problem mit der Berechtigung handelt versuchte ich das Gleiche als Admin, ebenfalls umsonst. Erst als ich die Zugriffsrechte der Partition von "System" auf "Admin" änderte, ging es.
Aber wieso ging das früher auch ohne diesen Umweg?
Um das verständlich zu machen, gilt es ein wenig weiter auszuholen und erst mal einige grundsätzliche Dinge zu erläutern. Zuerst mal etwas Info dazu, wie und wo ein jedes Mac OS überhaupt solche "Custom Icons" speichert (das hat sich schon seit 20 Jahren nicht wesentlich verändert).
Wenn du einer
Datei ein Custom Icon zuweist...
...wird dieses im Resourcenzweig (Resourcefork) der Datei selbst abgelegt, also quasi direkt an die Datei angeheftet. (Das Icon wird zu einem Teil der Datei.)
Gleichzeitig wird ein (für dich nicht sichtbares) Attribut-Bit der Datei gesetzt. Findet der Finder ein solches gesetztes Attribut vor, weiss er dass die Datei ein Custom Icon enthält das er anzeigen soll, und das versucht er dann auch.
Wird dieses Bit wieder zurückgesetzt, wird ein solches Icon auch nicht mehr angezeigt, man kann es also löschen, ohne es wirklich entfernen zu müssen. Das ist praktisch und schnell, aber bei Dateisystemfehlern kann das manchmal nervige Inkonsistenzen hervorrufen, wie zB das wiederauftauchen von vorher gelöschten Icons oder auch gelegentlich mal "zerschossenen" Pixelsalat, wenn zwar das Attribut gesetzt ist, aber ein dazu passendes Icon in den Resourcen der Datei gar nicht existiert.
Wenn du einem
Ordner ein Custom Icon zuweist...
(auch Volumes oder Pakete sind aus einem bestimmten Standpunkt aus betrachtet... "Ordner". Zwar sind das Ordner mit einigen sehr speziellen Besonderheiten, aber im Grunde dennoch immer Ordner, in vielerlei Hinsicht verhalten sie sich also gleich.)
...dann kann obiger Mechanismus nicht verwendet werden, denn Ordner haben gar keinen Resourcefork, in dem man irgend etwas unterbringen könnte.
Das Icon wird in diesem Fall als eine separate Datei innerhalb dieses Ordners gespeichert, benannt wird dieses File grundsätzlich als "
Icon\r". Diese Datei wird mit einem "unsichtbar"-Attribut versehen, so dass sie in den Fenstern des Finders per Default nicht erscheint.
(Das \r steht für ein weder druck- noch sichtbares Steuerzeichen, ein "Carriage Return". Diese Namenswahl soll verhindern, dass eine evtl. von dir selbst erstellte Datei namens "Icon" als ein solches Ordnersymbol fehlinterpretiert wird. Du kannst per Tastatur ein solches, solo am Namensende stehendes CR-Zeichen nämlich nicht eingeben...)
Zusätzlich wird -genau wie bei einer Datei auch- das "Custom Icon"-Attribut-Bit des Ordners gesetzt, um den Finder anzuweisen dieses Icon wahrzunehmen und dann auch darzustellen.
(Nicht verwirren lassen: Ordner haben zwar keinen Resourcefork, aber sehr wohl Attribute - jedenfalls in einem HFS Dateisystem. Neu bei OS X hinzugekommen: Bei anderen Dateisystemen werden diese Attribute mit einigen weiteren Tricks simuliert, so dass man sie auch dort verwenden kann.)
Ebenso gilt hier analog: Wird dieses Attribut zurückgesetzt, wird ein solches Icon nicht angezeigt, obwohl eine entsprechende Datei noch vorhanden wäre. Erst dieses Attribut veranlasst den Finder, nach einer solchen Icon-Datei zu suchen und sie ggf. zu verwenden.
Neu bei OS X hinzugekommen sind auch die ebenfalls vom Finder gepflegten, unsichtbaren Dateien namens ".DS_Store". Diese Dateien sind aber nicht für Custom Icons zuständig, sondern für andere Darstellungsparameter des Finders, wie zB die Anordnung von Icons, deren Darstellungsgrösse, die Spaltenabmessungen in der Listenansicht, Hintergrundfarbe oder -bild, Textgrösse, Anzeige von Thumbnails etc etc
Ausserdem gibt es dann noch einige Attribute, die zwar auf die gleiche Weise gespeichert werden wie die "Custom Icon"-Markierung (also nicht in diesen .DS_Store Dateien, sondern direkt im HFS-Dateisystem), die aber hier nur der Vollständigkeit halber erwähnt sind: "unsichtbar", "geschützt", "Suffix ausgeblendet", "Etikettenfarbe", "vom Finder erfasst", "als Kopie öffnen ('Formularblock')" und noch einige mehr, die zumeist nur für Programmierer von Relevanz sind.
So weit zu "alten Traditionen".
Jetzt noch ein bisschen "erweiterte" Information zu den Zugriffsrechten...
...es gibt davon noch
etwas mehr als das, was du im Finder sehen und manipulieren kannst. Das gesamte Spektrum aller Möglichkeiten eröffnet sich erst im Terminal (oder in anderen "spezielleren" Programmen).
Normalerweise ist es für dich als Benutzer überhaupt nicht erforderlich, auf die weiterführenden Möglichkeiten zur Rechtevergabe zuzugreifen. Es ist sogar
sehr problematisch das zu tun, denn du kannst damit die Sicherheit deines Systems vor "Malware" oder unbefugten Zugriffen
ratzfatz kompett in den Orkus blasen. Diese Features sind allesamt in dieser Hinsicht sehr sehr kritisch und es hat gute Gründe, sie vor dem "normalen" Benutzer verborgen zu halten. Nur manchmal ist es eben doch nötig, sich mit dieser recht komplexen Materie auseinander zu setzen... aber nur
ein Feature davon ist in diesem Kontext von Bedeutung:
Das "Sticky" Bit
Die Eigenschaft "sticky" (im Sinne von "klebrig") kann sowohl auf Dateien als auch auf Ordner angewendet werden, mit jeweils gänzlich unterschiedlicher Bedeutung. Die Anwendung auf Dateien ist aber seit geraumer Zeit absolut überflüssig geworden und kann komplett ignoriert werden.
Nicht so bei den Ordnern, dort ist "sticky" nach wie vor sehr wichtig und zeigt massive Wirkung.
(Auch hier wieder zu beachten: Volumes und Pakete sind auch nichts anderes als Ordner...)
Um einem weit verbreiteten Irrtum gleich vorweg zu begegnen:
Das Sticky-Bit hat nichts, aber auch rein gar nichts mit dem "Geschützt"-Attribut in den Finder-Informationen zu tun.
- Den Benutzer 'root' interessieren Zugriffsrechte prinzipiell nicht die Bohne. Er ist über jegliche Form von Dateirechten vollständig erhaben, und auch sticky hat demzufolge für ihn keinerlei Effekt. Natürlich aber besitzt er allzeit die souveräne Befugnis, auch diese Eigenschaft nach Belieben zu ändern - mit globaler Wirksamkeit für
alle anderen Benutzer, mit einer Ausnahme:
- Den
Eigentümer eines bestimmten Ordners betrifft das sticky-Bit auch nicht. Er kann diesen Ordner genauso bearbeiten wie einen Ordner ohne dieses Attribut.
Wie für die restlichen Zugriffsrechte auch gilt: Der Eigentümer des Ordners ist -neben root- der einzige, der diese Eigenschaft ändern darf.
- Bei der Gruppenzugehörigkeit des Ordners beginnt sticky Wirkung zu zeigen.
Sowohl für Gruppenmitglieder als auch für "alle" gilt eine einschneidende Beschränkung:
Das Anlegen völlig neuer Objekte bleibt absolut unberührt und funktioniert in üblicher Weise. Bei jeglichem Zugriff aber auf
bereits existierende Objekte bleibt dieser Zugriff auf
non-destruktive Aktionen beschränkt.
Das bedeutet konkret, das man ein Objekt weder löschen, noch verschieben oder umbenennen, noch sonst in irgendeiner Weise ändern darf, wenn jemand anderes der Eigentümer ist. Die Daten
anderer Benutzer bleiben -trotz eines grundsätzlich erteilten Schreibrechts auf den Ordner- für jede Manipulation absolut tabu. Aktionen, die keinerlei Änderungen mit sich bringen, sind aber weiterhin wie gewohnt möglich, ebenso der Zugriff auf alle
eigenen Objekte.
Um etwas besser zu verstehen, wozu sowas gut ist, einfach ein praktisches Beispiel, bei dem sticky zum Einsatz kommt: Das
Startvolume
Das Stammverzeichnis des Startvolumes bildet ja unter OS X die Wurzel des gesamten Dateisystems. Dort befinden sich eine ganze Menge Objekte, auf die niemand ausser des Systems selbst (vulgo: root) jemals einen ungehinderten Schreibzugriff erlangen darf. Es sollte selbstredend sein, dass nicht einmal ein Administrator so eben einfach mal den Systemordner löschen können darf. Auch der Ordner "Programme", die systemweite "Library" oder die vielen unsichtbaren Bestandteile des Unix-Unterbaus haben selbst für einen Administrator ein Tabu zu sein.
Innerhalb einiger dieser Objekte darf ein Admin zwar oft frei schalten und walten, diese Objekte selbst aber einfach nach Laune mit eigenen Namen zu verzieren oder nach Gusto in den Papierkorb zu schubsen wäre nicht besonders klug.
Ergo: Administratoren dürften im Grunde kein Schreibrecht auf das Startvolume besitzen.
Bei anderen Unix-Kindern wie Linux, BSD oder Blaukraut-OS ist das eine Selbstverständlichkeit. Dort hat einzig und allein root die Befugnis, diesen Ort des Dateisystems heimzusuchen. (Bei den meisten gibt es noch nicht mal so etwas wie eine Admin-Gruppe)
Benutzer von Mac OS waren aber von je her etwas völlig anderes gewöhnt und erwarten wie selbstverständlich die Option, dort nach Lust und Laune eigene Ordner erstellen zu dürfen oder auch Dateien nach Wahl dort zu deponieren.
(Der Begriff "Deponie" passt hierfür ziemlich gut... naja...)
Und dazu braucht es nun mal dieses vermaledeite Schreibrecht...
Was also tun? Sticky ist die Lösung.
Man trägt also wie üblich root als Eigentümer des Startvolumes ein. (Niemand sonst soll diese Einstellungen ändern können, also ist das unbedingt nötig)
Dann gibt man root vollen Schreibzugriff - eine rein formelle Geschichte, denn das hat er ja sowieso immer, trotzdem ist das obligatorisch.
Dann weist man als Gruppe "admin" und hierfür ebenfalls vollen Schreibzugriff zu, um allen Administratoren die gewünschten Freiheiten zu gewähren.
Der Rest der Welt (Die "Eingeschränkten Benutzer" und auch alle anderen Nutzerkonten) muss sich mit dem reinen Lesezugriff begnügen.
Tja, und dann setzt man das Startvolume eben noch Sticky. Und dieses "klebrige" Attribut hält, was der Name verspricht: Die Administratoren können zwar tun und lassen, was immer ihnen beliebt, aber wenn es um die essentiellen Objekte des OS geht (die allesamt root gehören), dann scheinen diese dennoch wie "festgeklebt" zu sein.
Dieses Verhalten will man auch bei einer ganzen Reihe weiterer Objekte genau so haben. Zur typischen Standardliste von "Fliegenfängern" gehören neben den Ordnern für Programme und der Library auch der versteckte Papierkorbordner, der Sammelordner für temporäre Dateien oder der für alle Benutzer beschreibbare Ordner "Für alle Benutzer" ( /Users/Shared/ )
All diese Objekte haben gemeinsam, dass man zwar ungehindert was reinwerfen können soll, aber wenns ums wieder herausholen geht - bitte immer nur das
eigene Zeug...
So. Und nun bist du vielleicht schon am erahnen, warum du bestimmte "Custom Icons" oder diverse .DS_Store Dateien nicht in erwarteter Weise bearbeiten kannst...
...du siehst zwar im Finder ein vermeintlich genügendes Zugriffsrecht, aber was hilft das bei Objekten deren Eigentümer du nicht bist, wenn Sticky im Spiel ist? Genau, nichts...
Ich nehme an, der Groschen ist längst gefallen. Trotzdem:
Wenn irgendwo in einem Sticky-Ordner ein altes (verwaistes) Custom Icon herumschwirrt, das nicht von dir selbst angelegt wurde...
Wenn irgendwo in einem Sticky-Ordner eine alte .DS_Store Datei herumschwirrt, die nicht von dir selbst angelegt wurde...
...musst du (bzw der in deinem Namen laufende Finder) dir die Zähne daran ausbeissen.
ACHTUNG!
Wie schon erwähnt, ist die Zuweisung von exakt spezifizierten Rechten im gesamten Dateisystem eine sicherheitstechnische Notwendigkeit von allerhöchster Wichtigkeit.
Und natürlich gilt das auch für Sticky, du darfst das
keinesfalls nach Wahl irgendwo zurücknehmen, nur um irgendwo ein wenig mehr Komfort zu erlangen oder eine kleinere Schwierigkeit zu umschiffen.
Stelle umgehend für die wichtigsten Objekte des Systems die erforderlichen Voreinstellungen wieder her (Festplattendienstprogramm --> Rechte reparieren).
Wenn dir künftig solche "Dateileichen" im Weg liegen, eliminiere sie einfach. Sobald es sich um wieder NEU angelegte Dateien handelt, stellt sich dir Sticky ja nicht mehr in den Weg.
Nachfrage:
Brauchst du Anleitung, wie man zB mit dem Terminal solche unerwünschten Dateiruinen entfernt/löscht?
Ach ja, ein kleiner Tip noch... bei den .DS_Store hat Apple ziemlichen "Murxx 2.0" produziert. Bei manchen Aspekten ist nämlich die
IN einem Ordner liegende Datei zuständig, für andere Aspekte aber diejenige, welche sich
NEBEN dem betroffenen Ordner (also eine Hierarchiestufe höher) befindet... Weia...
Und noch einer...
Nicht nur die Ordner haben Zugriffsrechte - auch die Custom Icon Dateien selbst und die .DS_Store natürlich auch. Wenn Schreibzugriffe auf diese Dateien
durch ihre eigenen Dateirechte verboten sind, dann sind sie das eben auch, ohne wenn und aber. Normalerweise setzt der Finder diese in brauchbarer Form, und auch evtl. dadurch auftretende Probleme vermag er recht grazil zu umgehen.
Aber falls du mal irgendwo mit einem anderen Werkzeug was an der Rechteverteilung geändert hast, ohne diese Dinge zu berücksichtigen, könnte da "der Wurm drin" sein...
