Forum>Software>neuer Ordner "neu zugewiesene Objekte" nach macOS 11 Update auf Schreibtisch

neuer Ordner "neu zugewiesene Objekte" nach macOS 11 Update auf Schreibtisch

Kissi
Kissi25.05.2108:48
Schon das dritte mal in Folge habe ich jetzt mit dem macOS 11 Update den Ordner "neu zugewiesene Objekte" auf dem Schreibtisch. Ich habe schon gegoogelt und versucht mich schlau zu machen, was das auf sich hat. Eine richtige Antwort habe ich jedoch nicht gefunden.
Der Ordner auf dem Schreibtisch scheint eine Verknüpfung zu sein. Der Inhalt finde sich nochmals unter:
"Macintosh HD Benutzer Geteilt Neu zugewiesene Objekte Konfiguration private etc"
Dort befindet sich eine Datei namens "group.system_default"
Es gibt auch eine PDF von Apple anbei wo beschrieben wird was das Aufsichtsamt hat. Jedoch ist das für mich leider nicht verständlich.
Der Inhalt lautet wie folgt:

Beim letzten macOS-Upgrade bzw. bei der letzten Dateimigration konnten einige deiner Dateien nicht an ihre neuen Speicherorte bewegt werden. Die betreffenden Dateien sind in diesem Ordner enthalten.
Konfigurationsdateien
Diese Konfigurationsdateien wurden von dir, einem anderen Benutzer oder von einer App verändert oder angepasst. Diese Modifikationen sind möglicherweise nicht mit dem letzten macOS-Upgrade kompatibel. Die modifizierten Dateien befinden sich im Ordner „Konfiguration“ in Unterordnern, die nach dem Ursprungsort der Dateien benannt sind.
Um eigene Konfigurationen wiederherzustellen, vergleiche deine Modifikationen mit den Konfigurationsänderungen, die während des macOS-Upgrades durchgeführt wurden, und kombiniere sie falls möglich.
Konfigurationsdateien mit dem Suffix „system_default“ wurden bearbeitet oder angepasst, die Änderungen dürfen jedoch auf dem System installiert bleiben. Die system_default-Version der Datei dient dazu, zu zeigen, wie die von Apple stammende Version dieser Datei aussähe. Es wird empfohlen, die beiden Dateien zu vergleichen und zu überprüfen, ob Änderungen übernommen werden sollen, die Apple an der Standardversion vorgenommen hat.



Vielleicht weiss ja jemand mehr.
THX
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
-1

Kommentare

MikeMuc25.05.2109:24
Kissi
Zu allererst könntest du mal versuchen, die beiden Dateien mit einem Texteditor vergleichen. Deine unveränderte Datei liegt in /etc, das Original, wie Apple sie gerne hätte, hast du ja bereits gefunden.
Vermutlich sind bei dir zusätzliche Benutzergruppen eingerichtet. Ganz genau wird es sicher Marcel Bresink erklären können
-1
RichMcTcNs25.05.2109:46
Da find ich z.B. zwei Dateien, die wohl irgendwas mit der mail.app zu tun haben. Und jetzt?
Ich hab keine Idee, was nun zu tun ist und hab deshalb bisher die Aliase auf dem Schreibtisch gelöscht, zugegeben mit einem unbehaglichen Gefühl.
0
MikeMuc25.05.2110:43
RichMcTcNs
Da find ich z.B. zwei Dateien, die wohl irgendwas mit der mail.app zu tun haben. Und jetzt?
Nun hättest du zB mal die Namen der Dateien und den Pfad zum Original posten können. Und mal probieren, ob man mit einem Texteditor da rein schauen kann aber nähere Angaben zu Problemen werden ja extrem überbewertet und helfen nur in extrem seltenen Fällen
+1
thomas b.
thomas b.25.05.2111:06
So recht werde ich aus den neu zugewiesenen Objekten nicht schlau. Für Normal-User ist es kaum verständlich, was man ggfs. damit machen könnte oder sollte. Bisher habe ich die Ordner stets in der Tonne entsorgt.
+7
Mr.Bue
Mr.Bue25.05.2111:47
thomas b.
Bisher habe ich die Ordner stets in der Tonne entsorgt.

Ich auch.
+9
KJM25.05.2112:16
Viel besser erklären kann man das eigentlich nicht, als Apple das in der mitgelieferten PDF-Datei tut. Wenn einem diese Erklärung nicht viel sagt, hat man sehr wahrscheinlich nicht den geringsten Bedarf, abweichende Einstellungen an den neu installierten Standard-Versionen dieser Dateien vorzunehmen.

Dann ist es nicht nur unproblematisch, die Aliasdatei auf dem Schreibtisch zu löschen, sondern auch die Originaldatei im Ordner Benutzer > Geteilt zu suchen und den Ordner Neu zugewiesene Objekte dort ebenfalls zu entsorgen.

Im gleichen Ordner Benutzer > Geteilt kann man zudem nachsehen, ob es dort noch Relikte älterer Updates (in einem Unterordner Previously Relocated Items) gibt. Den kann man dann ebenfalls löschen.
+2
RichMcTcNs25.05.2112:20
MikeMuc
Ich such eigentlich keine Einzelfall-Lösung, sondern eine Erklärung, was da passiert. Die Apple-Hinweise verstehe ich nicht. Warum erscheint diese Sammlung? Was ist allgemein mit den Dateien los? Muss ich mich darum kümmern?
Das ist so Apple-untypisch, dass ich geneigt bin, dem keine Bedeutung zuzumessen.
Vielleicht kannst Du ein bisschen Licht in die Sache bringen?
Danke!
0
MikeMuc25.05.2113:46
Ich finde, die bereits zitierte Erklärung von Apple sagt bereits alles (Es wurden Abweichungen vom Default bei bestimmten Dateien festgestellt. Die im Detail zu erklären geht nur, wenn man beide Dateien vergleicht. Zu welchen Prozessen die gehören, ergibt sich ja bereits aus dem Ablageort und Namen.
Wer es also genau wissen will, muss die Dateien untersuchen oder untersuchen lassen. Mehr kann ich da nicht zu sagen.
+2
Kissi
Kissi25.05.2113:49
@RichMcTcNs
geht mir genau so. Für einen Laien einfach unverständlich.
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
+4
Kissi
Kissi25.05.2114:09
Hier noch ein Beitrag von MTN, wo selbiges schon einmal unter macOS Catalina diskutiert wurde.
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
+1
pogo3
pogo325.05.2114:17
Na, mir gehts auch immer so, und bestimmt nicht Apple-Like. Solche Szenarien nach Updates kannte man so nicht vor Catalina. Es gab dazu auch noch ne weitere Diskussion hier, auch zum Ordner > Geteilt , den könne man wohl löschen wenn man sicher nicht vorhat noch mal eine Version zurückzugehen, als Richtung Catalina. Kann mich aber nicht mehr genau erinnern, bzw. hab ich den Thread jetzt auf die Schnelle nicht gefunden.
„Wann hört es endlich auf zu dauern.“
+2
Deichkind25.05.2116:34
Laut dieser Diskussion bei Reddit entspricht der Inhalt der Datei "group.system_default" jener Form, die Apple vorschlägt zu verwenden.

Es ist eine Textdatei. Die Datei group.system_default ist über das Kontextmenü mit TextEdit.app zu öffnen. Sie unterscheidet sich von der in /private/etc/group vorhandenen Version nur durch einen zusätzlichen Eintrag für die Gruppe "trustd". Der kam wohl mit macOS 11.2.3 hinzu.

Was die Einträge der Datei bedeuten, kann man im Terminal nach Eingabe von "man group" studieren.

Der Ersteller des Threads bei Reddit hat den Inhalt der Datei /private/etc/group durch den Inhalt der neuen Version ersetzt und bekam danach beim nächsten Update keinen Hinweis mehr.

Das Problem: Die /private/etc/group ist geschützt (jedenfalls bei mir auf Mojave. Ist das bei Big Sur anders?). Die kann man auf Mojave jedenfalls nicht ohne Weiteres ersetzen.
0
Kissi
Kissi25.05.2116:53
Habe ich das richtig verstanden, das ich die Datei "group.system_default" von Macintosh HD Benutzer Geteilt Neu zugewiesene Objekte Konfiguration private etc" durch die vom Schreibtisch ersetzten soll?
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
Deichkind25.05.2118:05
Nicht ganz. Die Datei auf dem Desktop ist ja nur eine Verknüpfung. Sie verweist auf die Datei group.system_default im Ordner Benutzer/Geteilt/… Ich glaube, Apple ist beim Herstellen von Big Sur ein Fehler unterlaufen: In der ursprünglich mit Big Sur gelierten Version der Datei group, die sich nach wie vor am Platz /private/etc/group befindet, fehlt der Eintrag für trustd. Die in group.system_default gelieferte Version hat nun endlich diesen Eintrag. Der Inhalt der Ursprungsversion in /private/etc/group muss also durch den Inhalt der neuen Version ersetzt werden, damit nicht bei jedem Update dieser Hinweis auf dem Desktop erneut erscheint.
Die Datei /private/etc/group wird, soweit zu lesen war, allenfalls im Single User Mode ausgewertet. Gibt es den bei Big Sur überhaupt noch? Normalerweise scheint es nicht zu stören, wenn man den Inhalt der Datei group einfach so belässt wie er jetzt ist.

Bei Stack Exchange gibt es ebenfalls eine Frage zu diesem Thema: . Und die Antwort ist dieselbe. Dort gibt es auch einen Link zu einer Diskussion bei MacRumors.
+3
Kissi
Kissi25.05.2118:16
Ok. Das ist dann doch etwas zu viel für mich
Danke für deine Mühe
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
RichMcTcNs25.05.2118:30
Deichkind
Vielen Dank für die Erläuterungen,die langsam Licht in die Sache bringen.
Aber soll wirklich meine Oma auf ihrem Macbook sowas machen? Was hat sich Apple dabei bloß gedacht!
Ich verstehe es immer noch nicht.
+1
pünktchen
pünktchen25.05.2118:35
Deichkind
Ich glaube, Apple ist beim Herstellen von Big Sur ein Fehler unterlaufen: In der ursprünglich mit Big Sur gelierten Version der Datei group, die sich nach wie vor am Platz /private/etc/group befindet, fehlt der Eintrag für trustd. Die in group.system_default gelieferte Version hat nun endlich diesen Eintrag.

Das entspricht aber so gar nicht der Erklärung im PDF. Und wenn das so ist, wieso ersetzt Apples Installer nicht einfach die fehlerhafte Version?
0
Deichkind25.05.2120:00
Ich weiß es nicht. Bei Stack Exchange gibt es noch ein weiteres Beispiel. In dem Fall betrifft es die Konfigurationsdatei shells: . Und in diesem Fall erinnert sich der Benutzer, dass er die Datei /private/etc/shells modifiziert hatte. Wer oder welche App hat jedoch die Datei private/etc/group modifiziert?

Übrigens: Welches Änderungsdatum hat die Datei private/etc/group? Die von Apple mit Big Sur gelieferten Dateien sind ja normalerweise vom 1. 1. 2020.
0
pünktchen
pünktchen25.05.2120:11
master.passwd.system_default hat das Datum 01.01.2020 9:00, group.system_default ebenfalls.

private/etc/master.passwd ist bei mir uralt, vom 16.09.15
private/etc/group hingegen vom 01.01.2020 9:00
+1
Deichkind25.05.2120:14
Aha. Das deutet doch stark darauf hin, dass beide Versionen von Apple stammen, private/etc/group und die erweiterte Variante group.system_default.
+1
Weia
Weia26.05.2115:15
Hm, also für Leute, die auf der Unix-Ebene arbeiten, ist der erläuternde Text von Apple völlig simpel zu verstehen. Andere sollten eigentlich gar nicht mit dem Problem konfrontiert werden.

Ich versuche mal, das noch verständlicher zu erklären:

Bei jedem OS-Upgrade einer bestehenden Installation gibt es ein prinzipielle Problem, was vom Nutzer vorgenommene Einstellungen betrifft:

Nutzer-Einstellungen werden stets in irgendeiner Form in einer Datei abgespeichert. Für Cocoa-Programme (also Programme mit GUI) sind das meist die bekannten .plist-Dateien in Library/Preferences/ im Nutzerordner. Für Unix-Programme und Nutzereinstellungen auf Systemebene sind das meist Dateien im Ordner /private/etc/.

Wenn bei einem OS-Upgrade neue Einstellungsmöglichkeiten ergänzt werden, entsteht nun prinzipiell das Problem, wie mit diesen Dateien verfahren werden soll, wenn das Betriebssystem nicht neu installiert wird, sondern eine vorhandene Installation (mitsamt aller Nutzereinstellungen) upgegradet wird:
  • Ersetzt man die bisherigen Dateien durch die Default-Versionen der neuen Betriebssystem-Version, sind auch die neuen Einstellungsmöglichkeiten enthalten, aber alle Einstellungen, die der Nutzer bislang gemacht hatte, sind verloren.
  • Lässt man die bisherigen Dateien bestehen, so bleiben alle Nutzereinstellungen erhalten, aber die neuen Einstellungsmöglichkeiten fehlen.

Daher ist es immer ein Frage der Abwägung, welche der beiden Strategien im jeweiligen Fall weniger Schaden anrichtet.

Zwei Beispiel aus der (anschaulichen) Cocoa-GUI-Welt:
  • Bei einem macOS-Upgrade (ich erinnere nicht mehr, welchem) wurden die Bedienelemente in der Werkzeugleiste von Vorschau-Fenstern ziemlich neu gestaltet. Hier entschloss sich Apple, die bisherigen Nutzereinstellungen bezüglich der Bedienelemente in der Werkzeugleiste komplett zu löschen und eine neue Default-Werkzeugleiste zu generieren mit all den neuen Bedienelementen. Jegliche bisherigen Nutzereinstellungen für die Werkzeugleiste waren damit verloren, aber nachdem diese Einstellmöglichkeiten überschaubar komplex sind, war das kein allzu großer Nachteil, während der Vorteil war, dass die Nutzer alle neuen Bedienelemente sofort zu Gesicht bekamen.
  • Bei einem anderen macOS-Upgrade (ich erinnere erneut nicht mehr, welchem) wurden die Bedienelemente in der Werkzeugleiste vom Mail-Hauptfenster um das Bewegen-Popup ergänzt, mit dem sich eingegangene Mails schnell in jene lokalen Ordner verschieben lassen, in die sie statistisch typischerweise vom Nutzer verschoben werden. Die Mail-Einstellungen sind allerdings derart komplex (allein die Einstellungen für die Mailkonten samt Zugangsdaten etc., dann die ganzen Regeln, …), dass die Vorteile klar überwogen, die alten Einstellungen nicht zu überschreiben. Der Nachteil war dann, dass bisherige Nutzer, die ein bestehendes System upgradeten, oft gar nicht oder nur viel später mitbekamen, dass es nun dieses praktische Popup gibt.

Und dasselbe Problem gibt es nun auch bei Unix-Dateien, in denen z.B. Nutzer und Gruppen, Netzwerkeinstellungen und lokale Server wie z.B. der in macOS eingebaute Mailserver konfiguriert werden.

Auch hier muss Apple abwägen, was größeren Schaden verursacht:
  • 1. Die bisherige Einstellungsdatei zu ersetzen (alle bisherigen Nutzereinstellungen werden gelöscht)
  • 2. Die bisherige Einstellungsdatei zu belassen (alle bisherigen Nutzereinstellungen bleiben erhalten, aber die neuen Einstellungsoptionen fehlen)

Das ist auf der Unix-Ebene sogar noch kritischer als bei Cocoa-Programmen, da letztere einige Mechanismen enthalten, das Problem zu lindern, etwa, indem sie „intelligent“ damit umgehen können, dass Einstellungsmöglichkeiten in der Einstellungsdatei fehlen, während Unix-Programme hier eventuelle Probleme meist weniger gut abfangen können und daher kritischer sind.

Apples Abwägung wird von Datei zu Datei verschieden ausfallen, aber damit die Nutzer auf alle Fälle nachvollziehen können, was geändert wurde bzw. welche neuen Einstellmöglichkeiten fehlen, wird die jeweils andere Datei eben im Ordner Neu zugewiesene Objekte abgespeichert:
  • Für Fall 1 die bisherige Einstellungsdatei, so dass Nutzer ein Backup ihrer bisherigen Einstellungen haben und diese, wenn gewünscht, erneut vornehmen können
  • Für Fall 2 die Datei mit jenen Einstellungen, die macOS bei einer Neuinstallation verwenden würde, so dass man sieht, welche Einstellungsmöglichkeiten hinzugekommen sind. Diese Dateien werden dadurch gekennzeichnet, dass .system_default an den Namen angehängt wird.

Eigentlich sollten mit alledem nur Nutzer konfrontiert werden, die auf der Unix-Ebene arbeiten (also Konfigurationsdateien in /private/etc/ selbst verändern) und dann auch Apples diesbezügliche Hinweise leicht verstehen können. Warum das bei Big Sur offensichtlich nicht so ist, kann ich nicht sagen, da ich noch mit Mojave arbeite.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
+11
RichMcTcNs26.05.2116:09
Weia
Danke! Gut angekommen.
0
Deichkind26.05.2117:01
In der von Apple gelieferten Erläuterung stimmen doch die Bezüge nicht:
Apple
Beim letzten macOS-Upgrade bzw. bei der letzten Dateimigration konnten einige deiner Dateien nicht an ihre neuen Speicherorte bewegt werden. Die betreffenden Dateien sind in diesem Ordner enthalten.
Gemeint sind nicht „meine Dateien“, sondern von Apple gelieferte Dateien.
Apple
Konfigurationsdateien
Diese Konfigurationsdateien wurden von dir, einem anderen Benutzer oder von einer App verändert oder angepasst. […] Die modifizierten Dateien befinden sich im Ordner „Konfiguration“ in Unterordnern, die nach dem Ursprungsort der Dateien benannt sind.
Ich sehe jetzt davon ab, dass in diesem Fall nicht zutrifft, was in der Erläuterung unterstellt wird. Also angenommen der Benutzer hätte Dateien modifiziert, dann hätte er ja nicht „diese [vom Installationsprogramm im Ordner ‚Geteilt‘ abgelegten] Konfigurationsdateien“ verändert, sondern jene, die sich noch an dem entsprechenden Ort im Systemordner befinden.
Apple
Um eigene Konfigurationen wiederherzustellen, vergleiche deine Modifikationen mit den Konfigurationsänderungen, die während des macOS-Upgrades durchgeführt wurden, und kombiniere sie falls möglich.
Auch hier ist es genau falsch herum beschrieben. Das macOS-Upgrade hat ja keine Modifikation durchgeführt, sondern die vom Benutzer (angeblich) modifizierte Datei am Ort belassen.
Apple
Konfigurationsdateien mit dem Suffix „system_default“ wurden bearbeitet oder angepasst, die Änderungen dürfen jedoch auf dem System installiert bleiben. Die system_default-Version der Datei dient dazu, zu zeigen, wie die von Apple stammende Version dieser Datei aussähe. Es wird empfohlen, die beiden Dateien zu vergleichen und zu überprüfen, ob Änderungen übernommen werden sollen, die Apple an der Standardversion vorgenommen hat.
Auch bei dem Rest kann ich keinen Sinn erkennen, außer dass der Suffix ".system_default" wohl eine Datei kennzeichnet, die sich in dem von Apple vorgesehenen Originalzustand befindet.
+3
Deichkind26.05.2117:18
Ich habe noch nie den Migrationsassistent benutzt. Der ist wohl ist wohl die Quelle des von Kissi zitierten Textbausteins?
0
Kissi
Kissi26.05.2118:06
Der von mir oben zitierte Text ist eine PDF Datei, die bei dem neuem Ordner bei war.



„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
Weia
Weia26.05.2119:35
Deichkind
In der von Apple gelieferten Erläuterung stimmen doch die Bezüge nicht:
Doch, die stimmen alle. Das läuft nur etwas anders ab, als Du dir vorstellst.
Apple
Beim letzten macOS-Upgrade bzw. bei der letzten Dateimigration konnten einige deiner Dateien nicht an ihre neuen Speicherorte bewegt werden. Die betreffenden Dateien sind in diesem Ordner enthalten.
Gemeint sind nicht „meine Dateien“, sondern von Apple gelieferte Dateien.
Nein, gemeint sind Deine Dateien, die via Migrationsassistent von Deiner alten Installation in die neue bewegt werden. Dieser Satz bezieht sich zunächst mal auf eine Migration. Wenn Du ein Upgrade auf einem schon vorhandenen System machst, werden intern auch erstmal alle schon vorhandenen Konfigurationsdateien, die nicht mit den alten Default-Dateien übereinstimmen, in einen eigenen Ordner bewegt (so dass zunächst mal das neue macOS in „einem Rusch“ installiert werden kann, ohne etwas zu überschreiben) und dann von dem wieder zurück an den Originalplatz, wenn der Migrationsassistent, der für die Entscheidung zuständig ist, beschließt, dass Deine alte Version verwendet werden sollte. Auch bei einem Upgrade an Ort und Stelle migrierst Du also quasi.
Apple
Konfigurationsdateien
Diese Konfigurationsdateien wurden von dir, einem anderen Benutzer oder von einer App verändert oder angepasst. […] Die modifizierten Dateien befinden sich im Ordner „Konfiguration“ in Unterordnern, die nach dem Ursprungsort der Dateien benannt sind.
Ich sehe jetzt davon ab, dass in diesem Fall nicht zutrifft,
Das trifft ganz sicher zu. Das muss ja keine Modifikation sein, die Du bewusst gemacht hast; das kann auch ein durch irgendwas (auch irgendein Programm) angestoßener automatischer Prozess sein. Du kannst Dir ja mit dem FileMerge Utility (aus der Xcode-Installation) genau ansehen, wo die Differenzen in den jeweils beiden Versionen liegen.
Also angenommen der Benutzer hätte Dateien modifiziert, dann hätte er ja nicht „diese [vom Installationsprogramm im Ordner ‚Geteilt‘ abgelegten] Konfigurationsdateien“ verändert, sondern jene, die sich noch an dem entsprechenden Ort im Systemordner befinden.
Ja, natürlich, aber die wird im Rahmen des Upgrades eben erstmal woanders hinkopiert.
Apple
Um eigene Konfigurationen wiederherzustellen, vergleiche deine Modifikationen mit den Konfigurationsänderungen, die während des macOS-Upgrades durchgeführt wurden, und kombiniere sie falls möglich.
Auch hier ist es genau falsch herum beschrieben. Das macOS-Upgrade hat ja keine Modifikation durchgeführt, sondern die vom Benutzer (angeblich) modifizierte Datei am Ort belassen.
Ich weiß nicht, worin Du dich hier verbeißt. Auch das ist völlig korrekt. Das ganze Problem tritt doch nur auf, wenn auch Apple die Konfigurationsdatei für die neue macOS-Version geändert hat. Wäre die unverändert, gäbe es doch gar kein Problem, dann könnten einfach Deine Änderungen, die ja auf der alten, gegenüber der neuen unveränderten Default-Datei basieren, beibehalten werden.

Der Konflikt entsteht nur, wenn Du und Apple parallel die Datei verändert haben und nun die Frage entsteht, welche der beiden parallel geänderten Versionen verwendet werden soll.

Nochmal zusammengefasst: In dem Ordner Neu zugewiesene Objekte befinden sich zwei Arten von Dateien:
  • Solche mit dem Suffix .system_default – dann hat der Migrationsassistent beschlossen, dass am Original-Ort Deine Version sein soll
  • Solche ohne das Suffix .system_default – dann hat der Migrationsassistent beschlossen, dass am Original-Ort Apples Version sein soll

Deichkind
Ich habe noch nie den Migrationsassistent benutzt. Der ist wohl ist wohl die Quelle des von Kissi zitierten Textbausteins?
Doch, den benutzt Du bei jedem Upgrade – Du merkst es nur nicht.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
+2
Deichkind26.05.2120:31
Weia, du hast anscheinend den Thread nicht komplett gelesen. Die beiden Dateien „group“, um die es hier geht, sind anscheinend beide Default-Versionen von Apple. Sie tragen das Datum 01.01.2020. Die erste ohne den Eintrag für trustd kam wohl ursprünglich mit Big Sur und wurde laut diesem Bericht bei Reddit auch noch mit 11.2.3 in dieser verkürzten Version geliefert. Die zweite Version mit dem Eintrag für trustd wird seit 11.3 mit jedem Update in group.system_defaults neu aufgetischt, wenn man nicht den Inhalt der alten Version durch jenen der neuen Version ersetzt.

Ich sehe jetzt allerdings ein, dass Apples Erläuterung ganz umfassend auch jene Fälle behandelt, bei denen eine vom Administrator bearbeitete Konfigurationsdatei nicht in die neue Systemversion übernommen wurde, sondern in den Ordner /Benutzer/Geteilt verschoben worden ist. Solch ein Fall liegt in diesem Beispiel nicht vor. Und besonders gelungen finde ich Apples Erläuterung ohnehin nicht.
+1
Weia
Weia26.05.2123:10
Deichkind
Weia, du hast anscheinend den Thread nicht komplett gelesen.
Doch, das schon, aber gerade deshalb habe ich die spezifische Ausgangsituation in dem langen Thread etwas aus den Augen verloren und bin eher auf die Frage von RichMcTcNs eingegangen:
RichMcTcNs
Ich such eigentlich keine Einzelfall-Lösung, sondern eine Erklärung, was da passiert. Die Apple-Hinweise verstehe ich nicht. Warum erscheint diese Sammlung? Was ist allgemein mit den Dateien los? Muss ich mich darum kümmern?
Deichkind
Die beiden Dateien „group“, um die es hier geht, sind anscheinend beide Default-Versionen von Apple. Sie tragen das Datum 01.01.2020. Die erste ohne den Eintrag für trustd kam wohl ursprünglich mit Big Sur und wurde laut diesem Bericht bei Reddit auch noch mit 11.2.3 in dieser verkürzten Version geliefert. Die zweite Version mit dem Eintrag für trustd wird seit 11.3 mit jedem Update in group.system_defaults neu aufgetischt, wenn man nicht den Inhalt der alten Version durch jenen der neuen Version ersetzt.
OK, dann Apple das an dieser Stelle versabbelt. Üblicherweise ändern sich Konfigurationsdateien nur bei den großen Upgrades, nicht bei den Updates. Wenn nun also diese Datei (weil Apple in Big Sur 11.0 einen Eintrag vergessen hatte) sich bei einem Update ändert, so folgert der Migrationsassistent fälschlicherweise, dass der Unterschied zu der 11.0er-Variante aus einer Nutzermodifikation der alten Version resultiert, die er sich aber nicht zu überschreiben traut, weswegen die neue Variante mit angehängtem Suffix .system_default im Ordner Neu zugewiesene Objekte landet. Abstellen kann man diesen Spuk folglich ganz einfach, indem man die 11.0er Version dieser Datei durch die neue im Ordner Neu zugewiesene Objekte ersetzt. Dann sind beim nächsten Update installierte und neue Version identisch und es sollte keinen Grund zum Ablegen der Datei im Ordner Neu zugewiesene Objekte mehr geben.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Claus Krüger27.05.2100:48
Danke!
Weia
Hm, also für Leute, die auf der Unix-Ebene arbeiten, ist der erläuternde Text von Apple völlig simpel zu verstehen. Andere sollten eigentlich gar nicht mit dem Problem konfrontiert werden.

Ich versuche mal, das noch verständlicher zu erklären:

Bei jedem OS-Upgrade einer bestehenden Installation gibt es ein prinzipielle Problem, was vom Nutzer vorgenommene Einstellungen betrifft:

Nutzer-Einstellungen werden stets in irgendeiner Form in einer Datei abgespeichert. Für Cocoa-Programme (also Programme mit GUI) sind das meist die bekannten .plist-Dateien in Library/Preferences/ im Nutzerordner. Für Unix-Programme und Nutzereinstellungen auf Systemebene sind das meist Dateien im Ordner /private/etc/.

Wenn bei einem OS-Upgrade neue Einstellungsmöglichkeiten ergänzt werden, entsteht nun prinzipiell das Problem, wie mit diesen Dateien verfahren werden soll, wenn das Betriebssystem nicht neu installiert wird, sondern eine vorhandene Installation (mitsamt aller Nutzereinstellungen) upgegradet wird:
  • Ersetzt man die bisherigen Dateien durch die Default-Versionen der neuen Betriebssystem-Version, sind auch die neuen Einstellungsmöglichkeiten enthalten, aber alle Einstellungen, die der Nutzer bislang gemacht hatte, sind verloren.
  • Lässt man die bisherigen Dateien bestehen, so bleiben alle Nutzereinstellungen erhalten, aber die neuen Einstellungsmöglichkeiten fehlen.

Daher ist es immer ein Frage der Abwägung, welche der beiden Strategien im jeweiligen Fall weniger Schaden anrichtet.

Zwei Beispiel aus der (anschaulichen) Cocoa-GUI-Welt:
  • Bei einem macOS-Upgrade (ich erinnere nicht mehr, welchem) wurden die Bedienelemente in der Werkzeugleiste von Vorschau-Fenstern ziemlich neu gestaltet. Hier entschloss sich Apple, die bisherigen Nutzereinstellungen bezüglich der Bedienelemente in der Werkzeugleiste komplett zu löschen und eine neue Default-Werkzeugleiste zu generieren mit all den neuen Bedienelementen. Jegliche bisherigen Nutzereinstellungen für die Werkzeugleiste waren damit verloren, aber nachdem diese Einstellmöglichkeiten überschaubar komplex sind, war das kein allzu großer Nachteil, während der Vorteil war, dass die Nutzer alle neuen Bedienelemente sofort zu Gesicht bekamen.
  • Bei einem anderen macOS-Upgrade (ich erinnere erneut nicht mehr, welchem) wurden die Bedienelemente in der Werkzeugleiste vom Mail-Hauptfenster um das Bewegen-Popup ergänzt, mit dem sich eingegangene Mails schnell in jene lokalen Ordner verschieben lassen, in die sie statistisch typischerweise vom Nutzer verschoben werden. Die Mail-Einstellungen sind allerdings derart komplex (allein die Einstellungen für die Mailkonten samt Zugangsdaten etc., dann die ganzen Regeln, …), dass die Vorteile klar überwogen, die alten Einstellungen nicht zu überschreiben. Der Nachteil war dann, dass bisherige Nutzer, die ein bestehendes System upgradeten, oft gar nicht oder nur viel später mitbekamen, dass es nun dieses praktische Popup gibt.

Und dasselbe Problem gibt es nun auch bei Unix-Dateien, in denen z.B. Nutzer und Gruppen, Netzwerkeinstellungen und lokale Server wie z.B. der in macOS eingebaute Mailserver konfiguriert werden.

Auch hier muss Apple abwägen, was größeren Schaden verursacht:
  • 1. Die bisherige Einstellungsdatei zu ersetzen (alle bisherigen Nutzereinstellungen werden gelöscht)
  • 2. Die bisherige Einstellungsdatei zu belassen (alle bisherigen Nutzereinstellungen bleiben erhalten, aber die neuen Einstellungsoptionen fehlen)

Das ist auf der Unix-Ebene sogar noch kritischer als bei Cocoa-Programmen, da letztere einige Mechanismen enthalten, das Problem zu lindern, etwa, indem sie „intelligent“ damit umgehen können, dass Einstellungsmöglichkeiten in der Einstellungsdatei fehlen, während Unix-Programme hier eventuelle Probleme meist weniger gut abfangen können und daher kritischer sind.

Apples Abwägung wird von Datei zu Datei verschieden ausfallen, aber damit die Nutzer auf alle Fälle nachvollziehen können, was geändert wurde bzw. welche neuen Einstellmöglichkeiten fehlen, wird die jeweils andere Datei eben im Ordner Neu zugewiesene Objekte abgespeichert:
  • Für Fall 1 die bisherige Einstellungsdatei, so dass Nutzer ein Backup ihrer bisherigen Einstellungen haben und diese, wenn gewünscht, erneut vornehmen können
  • Für Fall 2 die Datei mit jenen Einstellungen, die macOS bei einer Neuinstallation verwenden würde, so dass man sieht, welche Einstellungsmöglichkeiten hinzugekommen sind. Diese Dateien werden dadurch gekennzeichnet, dass .system_default an den Namen angehängt wird.

Eigentlich sollten mit alledem nur Nutzer konfrontiert werden, die auf der Unix-Ebene arbeiten (also Konfigurationsdateien in /private/etc/ selbst verändern) und dann auch Apples diesbezügliche Hinweise leicht verstehen können. Warum das bei Big Sur offensichtlich nicht so ist, kann ich nicht sagen
0
MikeMuc27.05.2109:28
Claus Krüger
Full Quotes wie deines sind grad in der Mtn App auf einem iPhone nicht so toll. Wenn man dann nur ein Wort selber dazu schreibt entspricht das auch nicht der Nettiquette
Wenigstens war deine Antwort vor dem Quote...
+1
Kissi
Kissi27.05.2115:29
Ich fasse nochmal kurz zusammen.
Bei dem Update wollte Apple eine Datei, in meinem Fall "group.system_default", ändern.
Dieses konnte jedoch nicht umgesetzt werden. Nun solle ich die Dateien vergleichen und ggf. diese dann kombinieren.
Nur finde ich meine besagte Datei zum Vergleichen ja gar nicht, da diese ausgeblendet ist.
Da der Mac scheinbar trotzdem funktioniert kann ich dann die hinterlegte Datei ja löschen.
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
Weia
Weia27.05.2115:38
Kissi
Bei dem Update wollte Apple eine Datei, in meinem Fall "group.system_default", ändern.
Dieses konnte jedoch nicht umgesetzt werden.
Es wurde vorsichtshalber von macOS nicht automatisch umgesetzt. Gekonnt hätte macOS dies schon. Die Vorsicht war wie beschrieben in diesem speziellen Falle aber unnötig.
Nun solle ich die Dateien vergleichen und ggf. diese dann kombinieren.
Nö, Du sonst einfach die alte durch die neue Datei ersetzen. Du hast an der alten Datei selbst ja keine Modifikationen vorgenommen, nehme ich mal an.
Nur finde ich meine besagte Datei zum Vergleichen ja gar nicht, da diese ausgeblendet ist.
Dann blende sie doch einfach ein. Im Finder . (Punkt) und Du siehst alle Dateien. (Erneut derselbe Befehl schaltet das wieder aus.)
Da der Mac scheinbar trotzdem funktioniert kann ich dann die hinterlegte Datei ja löschen.
Auf gar keinen Fall! Es kann Probleme geben mit der alten Version, auch wenn Du die jetzt nicht bemerkst, also solltest Du unbedingt die alte Version durch die neue Version ersetzen. Abgesehen davon würde Dir ansonsten bei jedem Update wieder die neue Version auf den Rechner gespielt …
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Deichkind27.05.2116:31
Die alte Datei durch die neue zu ersetzen, geht vielleicht leichter als ich dachte. Apple wird ja wohl die Zugriffsrechte der Ersatzdatei so gesetzt haben wie es für den Betrieb erforderlich ist, also "System: Lesen & Schreiben", "wheel: Nur Lesen", "everyone: Nur lesen" (bitte nachsehen im Fenster "Informationen" des Finders).

Dann kannst du die alte Datei "group" im Ordner "private/etc/" umbenennen in z.B. "group_alt" (ein Dialogfenster fordert zum Vollziehen der Änderung das Eingeben von Administrator-Name und Administrator-Passwort an).

Sodann ist die neue Version der Datei dort hinein zu schieben, und der Suffix ".system_default" ist zu entfernen. Bei jedem Schritt wird das Administrator-Passwort angefordert.

Ich habe derartiges noch nicht gemacht. So stelle ich mir jedenfalls die Vorgehensweise vor.
0
pünktchen
pünktchen27.05.2116:36
Geht genau so. Wenn mein Mac gleich nicht mehr startet seid ihr schuld!
0
Kissi
Kissi27.05.2117:14
So habe ich es jetzt auch gemacht und bis jetzt scheint alles zu funktionieren. Mal sehen ob's das dann war.
Nochmals vielen Dank für eure Geduld und Ausdauer.
Liebe Grüße
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
OleHH27.05.2119:27
Ich lösch das Ding einfach immer. Der Mac funktioniert trotzdem einwandfrei. Keine Ahnung, was Apple mit dem Ordner von mir will. Ich nutze ja den Mac, weil ich genau mit so einem Zeug nichts zu tun haben will.
0
Kissi
Kissi27.05.2120:33
Ich erhoffe mir mit der Aktion einfach nur, das mir das beim nächsten Update erspart bleibt
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
0
Weia
Weia27.05.2121:13
OleHH
Ich lösch das Ding einfach immer. Der Mac funktioniert trotzdem einwandfrei.
Glaubst Du.
Keine Ahnung, was Apple mit dem Ordner von mir will.
Das haben wir doch jetzt geklärt. Apple will, dass Du die Datei aus dem Ordner an ihren vorgesehenen Ort verschiebst und die alte, dort bereits befindliche Datei gleichen Namens löscht/überschreibst.
Ich nutze ja den Mac, weil ich genau mit so einem Zeug nichts zu tun haben will.
Ist ja normalerweise auch so. In dem Fall gab es aber eben einen Bug. Ist es wirklich so viel schwieriger, diese doofe Datei einmal an ihren korrekten Ort zu verschieben, als sie bei jedem kommenden Update erneut zu löschen?
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
Kissi
Kissi22.07.2114:48
So, heute nun Update auf macOS 11.5 gemacht und siehe da, es wurde kein neuer Ordner "neu zugewiesene Objekte" mehr erstellt
Danke für eure Hilfe
„iMac 27 Zoll 2020 3.1GHz i5 • 24GB RAM • 256GB SSD • OS X 11.X / iPad 2017 WiFI / iPhone X / Apple Watch Series 3“
+2
Peter Eckel22.07.2119:24
Weia
Ist ja normalerweise auch so. In dem Fall gab es aber eben einen Bug.
Das ist leider so nicht immer ganz richtig.

Die Dateien lösen ein Dilemma: Der Benutzer (oder eine Software, oder was auch immer) hat eine Systemdatei in einer älteren Version modifziert. Das aktuelle Systemupdate liefert auch eine neue Version der Datei mit. Und jetzt kommt der eigentliche Konflikt: Welche der Änderungen soll erhalten bleiben? Wenn der Systemupdate die Datei einfach überschreibt, geht möglicherweise etwas, auf das sich der Benutzer verläßt, nicht mehr. Wenn nicht, funktioniert möglicherweise eine Systemkomponente nicht oder nicht richtig.

Also legt der Updater die geänderten Dateien gut sichtbar und mit einem erklärenden Dokument auf den Schreibtisch. Der Benutzer nun soll seine Änderungen prüfen, gegebenenfalls in die neuen Dateien einbauen, und danach die alten geänderten Dateien mit den neuen ersetzen.

Bei Versionskontrollsystemen wie svn oder git heißt sowas dann "merge conflict" und erfordert in der Regel auch manuelle Interaktion.
„Ceterum censeo liberum facierum esse delendum.“
0
pogo3
pogo322.07.2120:03
So, ich hatte auch wieder den Ordner der "Neu zug. Objekte" auf dem Destop.
Dann sagt mir jetzt bitte wo ich die hinschieben soll, ich kann die zu überschreibenden "Originale" noch nicht mal finden. Also bitte:

Und dann hab ich noch diverse Eintragungen z.Bsp.:


Ich bin kein Systemadministrator, da hab ich nicht gelernt sorry. Und keine schlauen Sprüche jetzt, ich finde das absurd von mir zu erwarten ich würde da in der Library Daten überschreiben. Ich kann's nicht, also brauch ich Hilfe.
„Wann hört es endlich auf zu dauern.“
0
pogo3
pogo322.07.2120:05
Der Benutzer nun soll seine Änderungen prüfen, gegebenenfalls in die neuen Dateien einbauen, und danach die alten geänderten Dateien mit den neuen ersetzen.

Bei Versionskontrollsystemen wie svn oder git heißt sowas dann "merge conflict" und erfordert in der Regel auch manuelle Interaktion.
Absurd. Absurd ist das.
„Wann hört es endlich auf zu dauern.“
-1
pogo3
pogo322.07.2120:07
Ist es wirklich so viel schwieriger, diese doofe Datei einmal an ihren korrekten Ort zu verschieben, als sie bei jedem kommenden Update erneut zu löschen?
Ja. Ich will nur das die Maschine funktioniert, sicher und einfach funktioniert. Ich kann das nicht, also erbitte ich um Hilfe.
„Wann hört es endlich auf zu dauern.“
0
Weia
Weia22.07.2120:37
pogo3
So, ich hatte auch wieder den Ordner der "Neu zug. Objekte" auf dem Destop.
Dann sagt mir jetzt bitte wo ich die hinschieben soll
Na, genau wie in Deinem Screenshot angegeben – noch klarer geht doch nun wirklich nicht:

Nach /private/etc/ bzw. /private/etc/postfix/.

Bei allen Dateien löscht Du zuvor das Suffix .system_default und überschreibst somit die bisher dort befindlichen gleichnamigen Dateien. Das Überschreiben wirst Du bestätigen müssen und auch das admin-Passwort angeben.

Der Ordner /private wird als Unix-Ordner normalerweise nicht angezeigt im Finder, deshalb drücke einmal . (Shift-Command-Punkt), um ihn sichtbar zu machen. (Mit demselben Befehl kannst Du das nachher wieder ausschalten.)
Ich bin kein Systemadministrator, da hab ich nicht gelernt sorry.
Aber da muss man nix lernen. Man muss einfach ein paar Dateien im Finder verschieben. Das machst Du sonst doch sicher auch?
Und dann hab ich noch diverse Eintragungen z.Bsp.:
Die hast Du nur, weil Du beim ersten Auftauchen dieses Ordners das nicht gleich erledigt hast. Alle Folgeordner wären Dir sonst erspart geblieben.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
+1
Weia
Weia22.07.2120:42
Peter Eckel
Weia
Ist ja normalerweise auch so. In dem Fall gab es aber eben einen Bug.
Das ist leider so nicht immer ganz richtig.
Doch, es gab hier einen Bug.
Die Dateien lösen ein Dilemma: Der Benutzer (oder eine Software, oder was auch immer) hat eine Systemdatei in einer älteren Version modifziert.
Schon klar. Aber wenn der Nutzer gar keine Dateien auf Unix-Ebene modifiziert hat, dann sollte er davon auch verschont bleiben. Das klappt normalerweise, aber in diesem einen Fall eben nicht.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
+1
pogo3
pogo322.07.2120:55
Weia

Vielen herzlichen Dank, ich denke ich habs geschafft. Muss ich noch irgendwas tun? Neustart etc.?
Was passiert jetzt? Und bitte verzeih, ich hoffe nur das alles gut gegangen ist, ich finde schon dass die Sache so nicht sein kann.

Ich hab noch welche gefunden:
„Wann hört es endlich auf zu dauern.“
0
pogo3
pogo322.07.2121:00
„Wann hört es endlich auf zu dauern.“
0
pogo3
pogo322.07.2121:29
Und noch:

„Wann hört es endlich auf zu dauern.“
0
Weia
Weia22.07.2122:36
pogo3
Vielen herzlichen Dank, ich denke ich habs geschafft. Muss ich noch irgendwas tun? Neustart etc.?
Neustart ist nicht kritisch, aber ganz am Ende einen machen ist sicherheitshalber sinnvoll.
Was passiert jetzt?
Hoffentlich gar nix. Oder höchstens sowas wie, dass Dein Mac plötzlich Geld zu drucken beginnt.
Und bitte verzeih, ich hoffe nur das alles gut gegangen ist,
Bestimmt, das ist alles kein sonderlich kritisches Zeugs.
ich finde schon dass die Sache so nicht sein kann.
Nein, natürlich sollte das nicht so sein. Aber manchmal gehen Dinge eben schief.
Ich hab noch welche gefunden:
Dann mache das damit genauso. Aber schaue bitte auf das Erstellungsdatum der Ordner und installiere von jeder Datei nur die neueste Also, von neuester Version zu älteren Versionen vorarbeiten, und wenn dann dieselbe Datei nochmals auftaucht, ignorieren. Nicht, dass Du unnötigerweise Dir die Arbeit machst und eine bestimmte Datei immer wieder mit noch neueren Versionen überschreibst.
„Not every story must end with a battle (Ophelia, in der umwerfend guten feministischen Adaption des Hamlet-Stoffes in dem Film „Ophelia“)“
0
KJM23.07.2100:52
Weia's Rat, diese beim MacOS-Upgrade aussortierten Dateien einfach wieder an ihren Ursprungsort zu legen, könnte riskant sein. Apple sagt in der erklärenden PDF-Datei deutlich, dass diese Datei Änderungen gegenüber der Apple-Grundausstattung enthält, die möglicherweise nicht mehr kompatibel zur neuen Systemversion sind. Apple hat die Datei an ihrem Ursprungsort bereits durch eine neue, saubere, kompatible Version der Datei, sozusagen die Grundausstattung, ersetzt.

Es ist sinnvoll, Apple's Vorschlag zu folgen und die beiden Datei-Versionen auf Unterschiede zu überprüfen. Änderungen aus der aussortierten Datei sollte man nur dann in Apples Grundausstattungsdatei übernehmen, wenn man weiß, was sie bedeuten und von welchem Programm / Installer sie veranlasst wurden. Ich gehe allerdings davon aus, dass Programme, die bemerken, dass sie nicht mehr über benötigte Zugriffsrechte verfügen, sich schon melden werden, um diese Rechte erneut zugeteilt zu bekommen.

Weiß man nicht, wozu die geänderten Einträge gehören, dann ist es m.E. besser, es bei Apples neu angelegter, sauberer Datei zu belassen und allenfalls die störende Aliasdatei "Neu zugewiesene Dateien" auf dem Schreibtisch zu löschen.

Die aussortierten Dateien selbst nehmen so wenig Platz in Anspruch, dass das Löschen oder das weitere Aufbewahren im Ordner Benutzer/Geteilt/ keinen nennenswerten Unterschied macht.
0

Kommentieren

Sie müssen sich einloggen, um sich an einer Diskussion beteiligen zu können.