Wie kann man die UUID eines Volumes unter Mac OS X in einen SPECIFIED-Wert ändern?

Ich habe das angegangen. Ich habe die Quelle für heruntergeladen hfs.util, die von Ihnen erwähnten Änderungen vorgenommen (damit sie kompiliert werden konnte), die UUID-Funktionalität (wie -s, die in der aktuellen Quelle deaktiviert ist) erneut aktiviert und ein neuer Befehl hinzugefügt (-S, der verwendet wird.) Geben Sie eine UUID an.

Das Format für den neuen Befehl lautet wie folgt:

sudo hfs.util -S disk0s2 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 

Sie müssen sudo verwenden oder als Root ausgeführt werden, aber Sie müssen das Volume NICHT (auch wenn es sich um Ihr aktuelles Systemvolume handelt) von der Bereitstellung aufheben.

Trotzdem debugge ich immer noch (ich bin schrecklich mit C). Ich kann es fehlerfrei ausführen, aber es ist immer noch effektiv, die neue UUID mit -S zu randomisieren. Unabhängig von der von mir angegebenen UUID bekomme ich immer noch eine andere.

Wenn es funktioniert, poste ich hier entweder ein diff, oder ich finde einen Ort, an dem die geänderte Quelle hochgeladen werden kann, und verlinkt von hier aus darauf.

Wenn ich versage, werde ich wahrscheinlich immer noch den Diff posten, und vielleicht kann jemand anderes (der mit C besser ist) das Problem beheben.

BEARBEITEN: OK. Ich habe herausgefunden, dass es einen großen Fehler mit Funktionen gibt, die die binären Funktionen der UUID-Zeichenfolge <-> im Apple-Quellcode verarbeiten hfs.util. Als binärer Wert werden 4 (unsignierte) 32-Bit-Wörter benötigt, um eine 128-Bit-UUID zu speichern. Die Apple-Quelle scheint nur 16 Hexadezimalzeichen zu verarbeiten (es sollte aus 16 Oktetten mit jeweils 2 Hexadezimalzeichen bestehen).

Es scheint auch, eine defekte Struktur zum Halten der UUID zu verwenden (es scheint nur ein "hohes" 32-Bit-Wort und ein "niedriges" 32-Bit-Wort zu speichern, aber es würden 4 (vorzeichenlose) 32-Bit-Wörter benötigt). Ich kann denken, ich kann das Problem beheben, aber ich muss die Struktur und alle Funktionen, die die Struktur verwenden, ändern (es kann also eine Weile dauern).

BEARBEITEN SIE # 2: Nachdem ich zu viel Zeit mit dem Debuggen der Apple-Quelle für hfs.util verbracht habe (ich bin wirklich kein C-Programmierer), scheint es, dass Apple beim Umgang mit einer UUID absichtlich nur 64-Bit verarbeitet. Der Rest wird aus einem Hash einer 64-Bit-Konstante, Computerkomponentenwerten, der aktuellen Uhrzeit usw. generiert. Wenn Sie also denselben 64-Bit-Schlüssel zweimal verwenden, erhalten Sie immer noch zwei verschiedene UUIDs (selbst wenn Sie denselben Computer verwendet haben, hat sich die Zeit noch geändert). Solange das eigentliche Schreiben in den Volume-Header die tatsächliche UUID (und nicht nur einen Schlüssel) sendet, und solange der Volume-Header die tatsächliche UUID speichert (und nicht nur einen Schlüssel und / oder Werte, die zur Berechnung verwendet werden können) UUID), dann gibt es Hoffnung. Mein Debugging ist noch nicht so weit gekommen. Ich werde wieder posten, wenn ich mehr weiß.

Ich habe mir den Quellcode von hfs.util nicht angesehen und es ist wahrscheinlich zu spät, um für Sie nützlich zu sein, aber ich denke, ich kann etwas Nützliches einbringen.

Die für HFS + -Datenträger verwendeten UUIDs scheinen alle der von der UUID-Spezifikation abgedeckten Variante zu sein und vom Typ der Version 3 zu sein, d. H. Ein Namespace und ein Name, der über MD5 in eine UUID konvertiert wird (siehe Details zu Wikipedia ).

Es ist wahrscheinlich, dass die tatsächliche Plattenkennung (die an die Stelle des Namens in der Spezifikation tritt) nur 64 Bit beträgt, die gemäß der Spezifikation in eine 128-Bit-UUID umgewandelt wird, indem die UUID des von Apple für die Volume-Kennungen verwendeten Namespaces vorangestellt und anschließend angewendet wird ein MD5-Hash

Dies beinhaltet keine Computerkomponentenwerte, aktuelle Uhrzeit usw. Diese werden für andere Arten von UUIDs verwendet. Es handelt sich jedoch um eine UUID "Namespace" (um die Tatsache zu identifizieren, dass wir einen Datenträger "benennen") und dann einen "Namen" (den tatsächlichen Bezeichner des Datenträgers).

Eine Sache, die mich zum Nachdenken anregt, ist nicht nur die Aussage von @ chriv, dass der Code nur 64 Bit zu verwenden scheint, sondern auch die Art und Weise, wie die UUIDs von dem "geheimen" Dienstprogramm behandelt werden, das mit SuperDuper geliefert wird!

Der SuperDuper! Das Sicherungsprogramm für Mac OS X verfügt über ein "verstecktes" Befehlszeilentool, mit dem Sie eine Volume-UUID abrufen und festlegen können. Es ruft es jedoch ab und setzt es als eine Folge von 64 Bits (ausgedrückt in Hex). Es scheint, als wären diese Bits ganz anders als die tatsächlichen Werte, die von den Apple-Festplatten-Dienstprogrammen gemeldet werden.

Weitere Informationen finden Sie unter:

http://www.shirt-pocket.com/forums/archive/index.php/t-1186.html

http://www.shirt-pocket.com/forums/archive/index.php/t-6173.html

Hinweis: Lesen Sie die Support-Diskussionen vollständig durch, da es so aussieht, als gäbe es ein paar Probleme, zum Beispiel einen Neustart.

Aktualisieren

Ich habe einen Blick auf Apple Quellen geworfen. Ich bestätige, was ich oben geschrieben habe. Was auf der Festplatte gespeichert wird, ist ein 64-Bit-Identifier für das Volume (der zufällig generiert wird, indem die ersten 64 Bit des SHA1-Hash eines Pseudo-Zufalls-Datenbits genommen werden: Betriebszeit, Startzeit, Host-ID, Hostname, Kernel-Release) Zeichenfolge, Kernelversionszeichenfolge, Lastdurchschnitt, VM-Statistiken und aktuelle Uhrzeit).

In Version 3 der UUID-Sprache ist dies ein "Name". Was auf der Platte gespeichert wird, ist also ein 64-Bit-Name des Volumes, nicht die UUID.

Die 128-Bit-UUID, die von den Tools gemeldet wird, wird nicht gespeichert. Sie wird jedes Mal zu Anzeigezwecken aus dem "Namen" und dem "Namespace" berechnet (der Namespace ist festgelegt und die kFSUUIDNamespaceSHA1-Konstante, zu der das OP manuell hinzugefügt werden musste) die Quelle, weil der Header fehlt, der sie enthält: Er stellt den "Namespace" für Volume-Namen dar (64-Bit-Dinge, die tatsächlich auf den Volumes gespeichert sind, um sie zu identifizieren).

Es ist einfach, vom "Namen" zur UUID zu wechseln (im Grunde wenden Sie den Standardalgorithmus für UUIDs der Version 3 an), im Grunde ist es jedoch unmöglich, von der UUID zum "Namen" zurückzukehren. Mit anderen Worten, die Antwort auf das OP lautet: Es ist möglich, wenn Sie den "Namen" des Datenträgers kennen (zum Beispiel, wenn Sie ein Backup auf eine neue Festplatte wiederherstellen möchten UND Sie den Namen sowie die Daten gespeichert haben)., aber nicht, wenn Sie nur die UUID kennen. Wenn Sie den Namen richtig einstellen, wird die erwartete UUID angezeigt. Sie benötigen den Namen und können ihn nicht aus der UUID berechnen.

Hinweise zu Apples Code (lesen Sie diese und schauen Sie sich den Code an und alles wird klar):

Wie ich schrieb, ist alles auf der Festplatte der "Name". Die UUID wird nur für die Visualisierung mit dem Algorithmus der Version 3 (eine UUID für einen "Namen" in einem "Namespace") berechnet.

• kFSUUIDNamespaceSHA1 ist wie oben erläutert die "Namespace" -Konstante .
• uuid_create_md5_from_name ist der UUID-Algorithmus der Version 3, der eine UUID der Version 3 mit einem "Namespace" und einem "Namen" berechnet.
• GenerateVolumeUUID erzeugt einen neuen zufälligen "Namen" (Hinweis: Nur der "Name", nicht die UUID, trotz des Funktionsnamens).

Das Festlegen und Abrufen des "Namens" auf die Festplatte hängt davon ab, ob der Datenträger aktuell gemountet ist. Der "Name" wird in der "Finder Info" des Volumes gespeichert. Das Abrufen und Einstellen der "Finder Info" -Daten für ein bereitgestelltes Volume kann mit getattrlist und setattrlist erfolgen. Wenn das Volume jedoch nicht gemountet ist, greifen sie auf den direkten Zugriff auf die Volume-Daten zu (dies ist immerhin Unix und ein nicht gemountetes Volume ist ein Block.) Gerät, auf das von root als Datei zugegriffen werden kann).

• SetVolumeUUID, SetVolumeUUIDRaw, SetVolumeUUIDAttr, GetVolumeUUID, GetVolumeUUIDRaw, GetVolumeUUIDAttr lesen / schreiben den "Namen" (wiederum behandeln sie trotz ihres Namens nur den "Namen" des Datenträgers, nicht die UUID). Die * Raw-Funktionen handhaben den direkten Zugriff über die Geräte- "Datei" für nicht gemountete Datenträger, die * Attr-Datenträger verwenden die get / setattrlist-API. Die einfachen prüfen, ob das Volume geladen ist, und rufen die entsprechende * Raw / * Attr-Version auf.

Dann gibt es die "High-Level" -Funktionen, die die Funktionalität des Tools implementieren:

• DoGetUUIDKey erhält den "Namen", passt das Endergebnis an und berechnet dann die UUID für die Anzeige.
• DoChangeUUIDKey erstellt einen neuen, zufälligen "Namen" und schreibt diesen auf das Volume.

Das Beste, was Sie tun können, ist, die gleiche Funktionalität des kleinen Befehlszeilentools, das in SuperDuper von Shirt Pocket enthalten ist, neu zu codieren! (Siehe die Links, die ich oben gepostet habe).