macos - How does one change the UUID of a Volume on Mac OS X to a SPECIFIED value?

This is similar to the question asked here:

How does one change the UUID of a Volume on Mac OS X 10.6?

Only difference is I want to change it to a specific value, not a random one. The hfs.util only seems to do random.

I considered modifying the hfs.util source to allow me to specify values. As I was poking around the code looking for where to begin making changes I remembered why C is not my favorite language. Several compile errors and segfaults later, I lost enthusiasm for trying to modify this tool. I'm willing to have a go at it again after I get some rest, but I figure there has got to be an easier way to change a volume's UUID that I just don't know of.

So before I waste anymore time, does anyone know of an easy way to do this? Or would any C experts like to join my endeavor in making hfs.util change the UUID to a specified value?

Here are the changes I made to be able to compile the tool from source OS X 10.6.8:

hfsutil_jnl.c:

47: #include 

hfsutil_main.c:

80: #include 
81: /* REMOVED */

And, as hinted in this article, added the following from line 166 in fs.c to hfsutil_main.c (since namespace.h isn't anywhere on the system):

static unsigned char kFSUUIDNamespaceSHA1[] = {0xB3,0xE2,0x0F,0x39,0xF2,0x92,0x11,0xD6,0x97,0xA4,0x00,0x30,0x65,0x43,0xEC,0xAC};

Lastly, I grabbed this file and added it to the working dir http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/hfs/hfs_fsctl.h

Answer

I havent looked into the source code of hfs.util and it is probably too late to be useful for you, but I think I can contribute something useful.

The UUIDs used for HFS+ volumes seem to be all of the variant covered by the UUID specification and be of the version 3 type, that is a namespace and a name converted to an UUID via MD5 (see details on wikipedia).

It seems likely that the actual disk identifier (taking the place of the name in the specification) is just 64 bits, converted into a 128 bits UUID according to the specification by prepending the UUID of whatever namespace Apple is using for volume identifiers and then applying an MD5 hash.

This does not involve computer component values, current time etc. Those are used for other kinds of UUIDs. However it does involve a "namespace" UUID (to identify the fact that we are "naming" a disk volume) and then a "name" (the actual identifier of the disk).

One thing that makes me think so is not only @chriv's statement that it the code seems to only use 64 bits but also the way the UUIDs are handled by the "secret" utility that comes with SuperDuper!

The SuperDuper! backup utility for Mac OS X has a "hidden" command line tool that would let you retrieve and set a volume UUID. But it both retrieves and sets it as a sequence of 64 bits (expressed in hex). And it seems those bits are quite different than the actual values reported by Apple disk utilities.

For more information see:

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

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

Note: read those support discussions all the way through as it seems there are some gotchas, like sometimes a need to reboot.

---

Update

I have glanced at Apple sources. I confirm what I wrote above. What is saved on disk is a 64bits identifier for the volume (which is generated randomly by taking the first 64 bits of the SHA1 hash of a set of pseudo random bits of data: uptime, boot time, host id, host name, kernel release string, kernel version string, load average, VM statistics and current time).

In Version 3 UUID parlance this is a "name". So what is saved on the disk is a 64bit "name" of the volume, not the UUID.

The 128bits UUID that is reported by the tools is not saved, it is computed each time, for display purposes, from the "name" and the "namespace" (the namespace is fixed and is that kFSUUIDNamespaceSHA1 constant the OP had to manually add to the source because the header containing it is missing: it represent the "namespace" for volume "names" which are the 64bit things that are actually saved on the volumes to identify them).

It's easy to go from the "name" to the UUID (basically you apply the standard algorithm for Version 3 UUIDs) but it's basically impossible to go back from the UUID to the "name". In other words the answer to the OP is: it's possible if you know the "name" of the volume (for example if you want to restore a backup to a new disk AND you have saved the name of it as well as the data), but not if you only know the UUID. Setting the name correctly will result in the expected UUID, but you need the name and cannot compute it from the UUID.

---

Notes on Apple's code (read these and look at the code and everything becomes clear):

As I wrote, all there is on disk is the "name". The UUID is computed only for visualization, using the Version 3 algorithm (an UUID for a "name" in a "namespace").

• kFSUUIDNamespaceSHA1 is the "namespace" constant, as explained above.


• uuid_create_md5_from_name is the Version 3 UUID algorithm that computes a Version 3 UUID given a "namespace" and a "name".


• GenerateVolumeUUID generates a new random "name" (note: just the "name", not the UUID, despite the name of the function).

Setting and getting the "name" to disk is different depending whether the volume is currently mounted. The "name" is stored in the "Finder Info" of the volume. Getting and setting the "Finder Info" data for a mounted volume can be done with getattrlist and setattrlist but if the volume is not mounted they resort to accessing the volume data directly (this is unix, after all, and an unmounted volume is a block device which is accessible, by root, as a file).

• SetVolumeUUID, SetVolumeUUIDRaw, SetVolumeUUIDAttr, GetVolumeUUID, GetVolumeUUIDRaw, GetVolumeUUIDAttr do read/write the "name" (again, despite their name, they only handle the "name" of the volume, not the UUID). The *Raw functions handle direct access via the device "file" for unmounted volumes, the *Attr ones use the get/setattrlist API. The plain ones check if the volume is mounted and call the appropriate *Raw/*Attr version.

Then there are the "high level" functions that implement the functionality of the tool:

• DoGetUUIDKey gets the "name", adjusts for endianness, then computes the UUID for display.


• DoChangeUUIDKey creates a new, random, "name" and writes it to the volume.

So the best you can do is re-code the same functionality of the little command line tool embedded in Shirt Pocket's SuperDuper! (see the links I posted above).