Mac os no uuids

• Закройте iTunes, если он запущен. cd

  /Music/iTunes/ литий> mv ‘iTunes Media’ ‘iTunes Media-bak’ литий> ln -s ‘SSD_Music/iTunes Media’ ‘iTunes Media’ литий>

• ditto ‘iTunes Media-bak’ ‘iTunes Media’ , чтобы скопировать медиа на новый диск. Пропустите это, если вы уже скопировали его.

Теперь, когда вы можете подключить диск по UUID, давайте автоматизируем его при входе в систему.

/Library/LaunchAgents/ , создайте новый файл с именем local.mount_SSD_Music.plist

Скопируйте /Вставьте следующий XML в новый файл, затем сохраните /выйдите.

Убедитесь, что диск размонтирован

Протестируйте установку с помощью нового планшета LaunchAgent с помощью launchctl load

/Library/LaunchAgents/local.mount_SSD_Music.plist . Надеюсь, он снова установил ошибки.

Итак, теперь, если вы перезагрузитесь, внешний накопитель будет автоматически установлен при входе в систему.

Надеюсь, это поможет!

Я сочетаю некоторые мои комментарии с ответом, поскольку считаю, что он обращается к проблеме fstab .

Как вы уже узнали, команда mount не может использовать UUID или LABEL и должен использовать идентификатор диска, например /dev/disk0s4 . Кроме того, возможно, майбехарри отметил, что метод OS X должен использовать diskutil . Чтобы ответить на ваше обновление . Однако fstab может использовать UUID или LABEL , просто посмотрите примеры на странице руководства для fstab . В терминальном типе fstab , а затем щелкните правой кнопкой мыши по fstab и выберите Open man Page. Прочтите его целиком! 🙂

У меня нет проблем с использованием fstab , но я всегда использую по крайней мере первые четыре поля. Я вижу, что в вашем комментарии отсутствует третье поле (fs_vfstype). Вы опускаете его в fstab ? Вы должны отредактировать свой вопрос и показать, что вы пробовали в fstab и какой редактор вы использовали.

Попробуйте: UUID=1738336E-68DD-46B1-997E-57469CF0472D /mount/point hfs rw,auto где /mount/point — существующий каталог.

Я тестировал это в своей системе, используя мой UUID , это ваш UUID в строке, которую я предлагаю вам попробовать выше.

Примечание: Он будет монтироваться только к определенной точке монтирования, если я включил третье поле (fs_vfstype), в противном случае оно смонтировано в /Volumes , хотя второе поле (fs_file) существует.

Источник

Как изменить UUID Тома в Mac OS X 10.6?

кто-нибудь знает, как изменить UUID Тома? Фон для этого вопроса заключается в том, что у меня есть дубликат UUID:

я /Volumes/OldMacHD С UUID XYZ. У меня /Volumes/Mirror1 С UUID XYZ (тот же UUID! Бьюсь об заклад, это потому, что OldMacHD был частью этого зеркала). Я получил эти UUIDs через:

Я хотел бы изменить UUID Mirror1 .

я случайно обнаружил hfs.util утилита, так как это тома HFS после все. The страница для hfs.util говорит, что если вы -s флаг, изменяет UUID. Однако, если ввести hfs.util само по себе, он не показывает вам -s вариант на всех, только каждый вариант, кроме этого! ГРР. Я все равно попробовал:

ничего не происходит. Нет сообщения об ошибке, нет сообщения об успехе. UUID точно такой же. Я попробовал, пока том был размонтирован.

6 ответов

синтаксис для hfs.util кажется просто devicename, а не путь, включая /dev/

обязательно размонтируйте диск перед hfs.util-s и держатель потом.

используйте» сырое » устройство, т. е. rdisk1s2 вместо disk1s2

diskutil info не будет показывать новый uuid, пока вы не перемонтируете.

Это должно быть выполнимо. попробуйте использовать hfs.util, указывающий фактический идентификатор устройства Тома (если это Том raid, вам нужен идентификатор устройства Тома raid, а не какого-либо конкретного диска).

в качестве альтернативы использовать маленький инструмент, который является частью SuperDuper! таким образом, можно указать путь к подключенному тому.

кровавые детали того, как обрабатывается идентификатор Тома (который на самом деле не является UUID, UUID используется только для отображения и пересчитывается каждый раз из фактический идентификатор Тома) объясняется в моем ответе как изменить UUID Тома в Mac OS X на указанное значение?

/dev/disk4 не является Томом HFS, это целый диск, включая таблицу разделов и любое количество отдельных томов (разделов) на диске. /dev/disk4s0 пример Тома. Найдите правильный идентификатор нужного Тома HFS и попробуйте сделать hfs.util -s об этом.

Вы можете просто изменить UUID форматом раздела / erase.

1) формат диска для Mac OS расширен с помощью встроенного Disk Utility

2) Если вам нужен раздел windows, отформатируйте диск в exFAT после того, как вы сделали первый шаг (по какой-то причине вам нужно два шага для раздела windows)

Вы можете проверить, изменился ли UUID, перечислив все номера UUID:

все примеры, которые я могу найти, просто берут имя устройства BSD, а не полный путь к файлу устройства. Вы когда-нибудь пробовали это?

самый простой и наиболее совместимый способ я нашел с Gparted (можно найти MAC dmg на sourceforge илиhttp://gparted.org) и вручную выбрать этот раздел / диск и редактирования uuid таким образом

но с диском util (это работает как на linux, так и на Mac:

выберите шестерню и выключите автоматическое крепление

в новых редактируемых полях изменить «Display Name», а затем выберите (из» mount as») mount as UUID=foo

• если ничего ценного не осталось на этом диске переформатировать и объявить отображаемое имя и монтировать как » $ (который будет uuid=foo)

(опционное) если необходимый re-enable автоматическая установка

(необязательно) измените fstab, чтобы повторно ввести сочетание дисков

Источник

Как генерируются UUID

Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.

Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.

Теория

UUID (universally unique IDentifier) — это 128-битное число, которое в разработке ПО используется в качестве уникального идентификатора элементов. Его классическое текстовое представление является серией из 32 шестнадцатеричных символов, разделённых дефисами на пять групп по схеме 8-4-4-4-12.

Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:

Значения на позициях M и N определяют соответственно версию и вариант UUID.

Версия

Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:

Вариант

Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.

Мы определяем его по первым 1-3 старшим битам на позиции N.

Сегодня чаще всего используют вариант 1, при котором MSB0 равняется 1 , а MSB1 равняется 0 . Это означает, что с учётом подстановочных знаков — битов, отмеченных х — единственными возможными значениями будут 8 , 9 , A или B .

1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B

Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.

Версия 1 (время + уникальный или случайный идентификатор хоста)

В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).

Идентификатор получают с помощью конкатенации 48-битного МАС-адреса, 60-битной временной метки, 14-битной «уникализированной» тактовой последовательности, а также 6 битов, зарезервированных под версию и вариант UUID.

Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.

Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.

Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.

Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.

Сборка UUID версии 1 происходит так:

1. Берутся младшие 32 бита текущей временной метки UTC. Это будут первые 4 байта (8 шестнадцатеричных символов) UUID [ TimeLow ].
2. Берутся средние 16 битов текущей временной метки UTC. Это будут следующие 2 байта (4 шестнадцатеричных символа) [ TimeMid ].
3. Следующие 2 байта (4 шестнадцатеричных символа) конкатенируют 4 бита версии UUID с оставшимися 12 старшими битами текущей временной метки UTC (в которой всего 60 битов) [ TimeHighAndVersion ].
4. Следующие 1-3 бита определяют вариант версии UUID. Оставшиеся биты содержат тактовую последовательность, которая вносит небольшую долю случайности в эту реализацию. Это позволяет избежать коллизий, когда в одной системе работает несколько UUID-генераторов: либо системные часы переводятся назад для генератора, либо изменение времени замедляется [ ClockSequenceHiAndRes && ClockSequenceLow ].
5. Последние 6 байтов (12 шестнадцатеричных символов, 48 битов) — это «идентификатор узла», в роли которого обычно выступает MAC-адрес генерирующего устройства [ NodeID ].

UUID версии 1 генерируется с помощью конкатенации:

Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.

Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.

Версия 2 (безопасность распределённой вычислительной среды)

Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.

Версия 3 (имя + MD5-хэш)

Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.

Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.

Обратите внимание, что namespace сам по себе является UUID.

В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.

Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.

При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.

Версия 4 (ГПСЧ)

Самая простая реализация.

6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.

Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.

В современных языках чаще всего используются UUID версии 4.

Её реализация достаточно простая:

1. Генерируем 128 случайных битов.
2. Переписываем некоторые биты корректной информацией о версии и варианте:

1. Берём седьмой бит и выполняем c 0x0F операцию AND для очистки старшего полубайта. А затем выполняем с 0x40 операцию OR для назначения номера версии 4.
2. Затем берём девятый байт, выполняем c 0x3F операцию AND и с 0x80 операцию OR.