Warum wird eine Befehlszeilenänderung in ~/Library/Preferences/com.apple.LaunchServices.plist nicht sofort wirksam?

Wenn das Info-Fenster von Finder verwendet wird, um Dateien eines bestimmten Typs mit einer Anwendung zu verknüpfen:

  • die Präferenz ist sofort wirksam.

Beim Terminal kommt eine vergleichbare Ergänzung zum Einsatz~/Library/Preferences/com.apple.LaunchServices.plist

  • die Einstellung ist nicht sofort wirksam.

Frage

Warum respektiert Launch Services einen Schreibvorgang an die com.apple.LaunchServices.plist?

Eine ideale Antwort könnte ein Verweis auf eine Seite im Apple-Entwicklerbereich sein.

Antworten müssen nicht das Ausführen eines Befehls beinhalten.

Hintergrund

Agent oder Dämon?

Ich fragte mich, ob ein Daemon oder Agent Änderungen an dieser .plist wirksam macht, und führte Folgendes aus:

sudo launchctl list

In der Liste unter der Label - Überschrift sehe ich nichts, was sich auf Launch Services beziehen könnte .

Verweise

Eine Antwort auf die Stack Overflow-Frage Wie wird die Standardanwendung für bestimmte Dateitypen in Mac OS X festgelegt? schlägt vor:

… neu geladen werden. Sie können sich abmelden, ein paar Minuten warten oder den Neustart von Launchservices erzwingen …

In meinem Fall:

Die akzeptierte Antwort auf die Super-User-Frage Gibt es eine schnellere Möglichkeit, Standard-Apps zu ändern, die mit Dateitypen unter OS X verknüpft sind? schlägt vor:

… das Betriebssystem neu starten, um die Änderungen zu übernehmen (abmelden und wieder anmelden reicht nicht) …

– Wenn ein Neustart ausreicht, ist das wahrscheinlich weniger zeitaufwändig als das Beenden und anschließende Seeding der Launch Services-Datenbank.

lsregister -kill -seeddauert nicht so lange (ein paar Sekunden auf meinem Air), aber OS X zeigt die Warnungen zum erstmaligen Öffnen von Anwendungen wieder an. Aus diesem Grund ist ein Neustart im Allgemeinen eine weniger lästige Methode, um die Änderungen zu übernehmen.

Antworten (1)

Aus Apples Launch Services Programming Guide (alle Hervorhebungen von mir):

Alle auf dem System des Benutzers verfügbaren Anwendungen müssen registriert werden, um sie Launch Services bekannt zu machen und ihre Dokumentenbindung und andere Informationen in ihre Datenbank zu kopieren. Normalerweise ist es nicht notwendig, diese Aufgabe explizit auszuführen, da sich eine Vielzahl von Dienstprogrammen und Diensten, die in die Mac OS X-Systemsoftware integriert sind, automatisch darum kümmern:

  • Ein integriertes Hintergrundtool, das immer dann ausgeführt wird, wenn das System hochgefahren wird oder sich ein neuer Benutzer anmeldet , durchsucht automatisch die Anwendungsordner in den System-, Netzwerk-, lokalen und Benutzerdomänen und registriert alle neuen Anwendungen, die es dort findet. (Dieser Vorgang entspricht dem „Neuerstellen des Desktops“ in früheren Versionen von Mac OS.)
  • Der Finder registriert automatisch alle Anwendungen, sobald er sie erkennt, z. B. wenn sie auf die Festplatte des Benutzers gezogen werden oder wenn der Benutzer zu einem Ordner navigiert, der sie enthält.
  • Wenn der Benutzer versucht, ein Dokument zu öffnen, für das keine bevorzugte Anwendung in der Launch Services-Datenbank gefunden werden kann, zeigt der Finder einen Dialog an, der den Benutzer auffordert, eine Anwendung auszuwählen, mit der das Dokument geöffnet werden soll. Anschließend wird diese Anwendung registriert, bevor sie gestartet wird.

Trotz dieser automatischen Registrierungsprogramme kann es manchmal erforderlich sein, eine Anwendung explizit bei Launch Services zu registrieren. Obwohl beispielsweise Entwickler ermutigt werden, ihre Anwendungen so zu verpacken, dass sie installiert werden können, indem sie einfach auf die Festplatte des Benutzers gezogen werden, erfordern einige Anwendungen möglicherweise eine ausgefeiltere benutzerdefinierte Installationssoftware. In solchen Fällen sollte das Installationsprogramm eine der Registrierungsfunktionen der Launch Services aufrufen LSRegisterFSRefoder LSRegisterURLdie Anwendung explizit registrieren.

Beachten Sie die API-Aufrufe, die von der einzigen benannten manuellen Registrierungsprozedur benötigt werden ( Quelle ist leider nicht auf opensource.apple.com verfügbar ).

Bei der Umgehung eines Fehlers bei der Verarbeitung von Startdiensten auf Leopard mit aktiviertem FileVault ist mir folgendes aufgefallen ~/Library/Preferences/com.apple.LaunchServices.plist:

  • nur bei der Anmeldung nach dem Booten verarbeitet, als Eingabedaten für den eigentlichen Aufbau der Launch Services-Datenbank (Leopard mit FileVault-Unterstützung hat diesen Schritt oft nicht ausgeführt, was zu scheinbar verlorenen Benutzereinstellungen führte); Und

  • zwischengespeichert, solange die Maschine nicht neu gestartet wird.

Einfach ausgedrückt, es ist die Benutzerdomänen-Persistenzschicht von Launch Services , und Änderungen an dieser Persistenzschicht werden nur bei der nächsten Verarbeitung bestätigt – Neustart oder Reseeding .

@GrahamPerrin: Übrigens, wenn Sie eine Möglichkeit brauchen, Einträge zur Launch Services-Datenbank hinzuzufügen, ohne mühsam schreiben com.apple.LaunchServices.plistund neu starten zu müssen, schauen Sie sich duti an – es ist das, was ich verwendet habe, um genau dasselbe Problem in GoodCompany zu umgehen .
Wo duti eine akzeptierte Antwort ist, gibt es einen Hinweis mit Aufzählungszeichen, dass ein Neustart/Neustart erforderlich ist . Möglicherweise weichen die Anforderungen ab, wenn FileVault 1 nicht verwendet wird? Nur eine Vermutung. Ich würde dies gerne im Ask Different Chat besprechen, wenn Sie möchten, sprechen Sie mich und @bmike an, wenn Sie möchten. Danke. (Meine diesbezüglichen Kommentare sind auf mehrere Fragen in mehreren Stapeln verteilt – nicht unbedingt eine schlechte Sache, aber ich hätte gerne einen einzigen Ort für Diskussionen.)
@GrahamPerrin: Ich werde versuchen, wann immer möglich im Chat zu sein, aber ich kann bereits berichten, dass kein Neustart erforderlich war, um den Standard-Handler für eine txtErweiterung zu ändern, die dutiauf meinem System (Lion, Nicht-FileVault) verwendet wird.
@GrahamPerrin Ich meinte, dass mein eigenes Skript (nicht duti) neu gestartet werden musste.
@Lri Ich sehe die letzte Ausgabe Ihrer Antwort, danke! Vielleicht gibt es aus der Open Source dutieine zusätzliche Antwort auf diese Frage oder eine Ausgabe der akzeptierten Antwort.
@GrahamPerrin: dutiist im Grunde ein CLI-Wrapper um die Funktionen LSSetDefaultRoleHandlerForContentTypeund LSSetDefaultHandlerForURLScheme, die beide Application.hzusammen mit den LSRegister*Funktionen deklariert werden – was bedeutet, dass es eine Schnittstelle mit Launch Services auf der von Apple bereitgestellten API-Ebene bildet, nicht über die Persistenzschicht (siehe die duti-Quelle, insbesondere handler. c ).