Я не изучал исходный код hfs.util, и, вероятно, уже слишком поздно, чтобы быть полезным для вас, но я думаю, что могу внести что-то полезное.
UUID, используемые для томов HFS+, по-видимому, представляют собой все варианты, охватываемые спецификацией UUID, и относятся к типу версии 3, то есть к пространству имен и имени, преобразованному в UUID через MD5 (см. Подробности в википедии).
Представляется вероятным, что фактический идентификатор диска (занимающий место имени в спецификации) составляет всего 64 бита, преобразуемого в 128-битный UUID в соответствии со спецификацией, добавляя UUID любого пространства имен, которое Apple использует для идентификаторов томов, и затем применяя хеш MD5.
Это не касается значений компонентов компьютера, текущего времени и т.д. Они используются для других типов UUID. Однако он включает в себя UUID "пространства имен" (для определения того, что мы "называем" том диска), а затем "имя" (фактический идентификатор диска).
Одна вещь, которая заставляет меня так думать, - это не только утверждение @ chriv о том, что код, похоже, использует только 64 бита, но и способ обработки UUID с помощью "секретной" утилиты, поставляемой с SuperDuper!
СуперДупер! Утилита резервного копирования для Mac OS X имеет "скрытый" инструмент командной строки, который позволит вам получить и установить UUID тома. Но он одновременно извлекает и устанавливает его как последовательность из 64 битов (выраженную в шестнадцатеричном формате). И кажется, что эти биты сильно отличаются от фактических значений, сообщаемых дисковыми утилитами Apple.
Для получения дополнительной информации см .:
http://www.shirt-pocket.com/forums/archive/index.php/t-1186.html
http://www.shirt-pocket.com/forums/archive/index.php/t-6173.html
Примечание: прочитайте эти обсуждения поддержки полностью, так как кажется, что есть некоторые ошибки, например, иногда требуется перезагрузка.
Обновить
Я взглянул на источники Apple. Я подтверждаю, что я написал выше. На диске сохраняется 64-битный идентификатор тома (который генерируется случайным образом, беря первые 64 бита хэша SHA1 из набора псевдослучайных бит данных: время работы, время загрузки, идентификатор хоста, имя хоста, выпуск ядра). строка, строка версии ядра, средняя загрузка, статистика ВМ и текущее время).
В UUID версии 3 это "имя". Поэтому на диске сохраняется 64-битное "имя" тома, а не UUID.
UUID в 128 битов, который сообщается инструментами, не сохраняется, он вычисляется каждый раз, для целей отображения, из "имени" и "пространства имен" (пространство имен фиксировано и является константой kFSUUIDNamespaceSHA1, к которой ОП пришлось вручную добавить источник, потому что заголовок, содержащий его, отсутствует: он представляет "пространство имен" для "имен" томов, которые являются 64-битными объектами, которые фактически сохраняются на томах для их идентификации).
Легко перейти от "имени" к UUID (в основном вы применяете стандартный алгоритм для UUID версии 3), но в принципе невозможно вернуться от UUID к "имени".
Другими словами, ответ на OP таков: это возможно, если вы знаете "имя" тома (например, если вы хотите восстановить резервную копию на новый диск и сохранили как имя, так и данные) , но не если вы знаете только UUID. Правильная установка имени приведет к ожидаемому UUID, но вам нужно имя и вы не можете вычислить его по UUID.
Примечания к коду Apple (прочитайте их, посмотрите на код, и все станет ясно):
Как я уже писал, все, что есть на диске, это "имя". UUID вычисляется только для визуализации с использованием алгоритма версии 3 (UUID для "имени" в "пространстве имен").
- kFSUUIDNamespaceSHA1 - это константа "пространства имен", как описано выше.
- uuid_create_md5_from_name - это алгоритм UUID версии 3, который вычисляет UUID версии 3 с учетом "пространства имен" и "имени".
- GenerateVolumeUUID генерирует новое случайное "имя" (обратите внимание: только "имя", а не UUID, несмотря на имя функции).
Установка и получение "имени" на диск зависит от того, смонтирован ли том в данный момент. "Имя" хранится в "Finder Info" тома. Получение и настройка данных "Finder Info" для смонтированного тома может быть выполнено с помощью getattrlist и setattrlist, но если том не смонтирован, они обращаются к прямому доступу к данным тома (в конце концов, это unix, а размонтированный том - блок устройство, которое доступно, как root, в виде файла).
- SetVolumeUUID, SetVolumeUUIDRaw, SetVolumeUUIDAttr, GetVolumeUUID, GetVolumeUUIDRaw, GetVolumeUUIDAttr выполняют чтение / запись "имени" (опять же, несмотря на их имя, они обрабатывают только "имя" тома, а не UUID). Функции * Raw обрабатывают прямой доступ через "файл" устройства для несмонтированных томов, а функции * Attr используют API get / setattrlist. Простые проверяют, смонтирован ли том, и вызывают соответствующую версию * Raw / * Attr.
Тогда есть функции "высокого уровня", которые реализуют функциональность инструмента:
- DoGetUUIDKey получает "имя", корректирует порядковый номер, а затем вычисляет UUID для отображения.
- DoChangeUUIDKey создает новое случайное имя и записывает его на том.
Поэтому лучшее, что вы можете сделать, это перекодировать ту же функциональность, что и маленький инструмент командной строки, встроенный в SuperDuper Shirt Pocket! (см. ссылки, которые я разместил выше).