В UDF, в чем разница между идентификатором тома, идентификатором набора томов, идентификатором логического тома и идентификатором набора файлов?

Я вижу, что mkudffsесть варианты для четырех разных идентификаторов: логический том ( --lvid), том ( --vid), набор томов ( --vsid) и идентификатор набора файлов ( --fsid). Это, однако, не дает никаких указаний на то, что они означают.

Итак, я пошел в спецификации UDF. Начиная с ISO / IEC 13346 или ECMA-167 , я обнаружил, что:

10.1.4 Идентификатор тома (BP 24)

В этом поле указывается идентификация объема.

14.1.10 Идентификатор логического тома (BP 112)

В этом поле указывается идентификация логического тома, на котором записан набор файлов.

14.1.12 Идентификатор набора файлов (BP 304)

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

Ну, это было полезно.

Итак, я попробовал OSTA UDF Spec 1.02 , так как это версия UDF, которую я пытаюсь сгенерировать. Это не сильно помогло (хотя и предостерегало меня от «фиксированных или тривиальных значений»).

Я попробовал спецификацию UDF 1.50, которая дополнительно говорит мне - в §4.1 - что перед отображением этих значений необходимо применить преобразование для конкретной ОС, используя алгоритмы, описанные в §4.1.2.1. Конечно, следующий раздел после §4.1 - это §4.2, так что удачи в этом. Кроме того, LogicalVolumeIdentifier является «чрезвычайно важным в идентификации логических томов, когда в музыкальном автомате присутствует несколько носителей. Обычно это имя отображается для пользователя».

Итак, я пробую спецификацию UDF 2.01 , и теперь я знаю, что к настоящему времени, по крайней мере, они поняли, что это 4. 2 .2.1, которая существует, но не помогает (она имеет дело с такими вещами, как наборы символов).

Итак, насколько я могу сказать:

• Идентификатор логического тома - это то, что отображается пользователю (возможно, только музыкальные автоматы). Так что должно быть установлено что-то значимое, например, название диска. Я предполагаю, что это название диска, которое будет отображаться в Windows, Mac OS или Nautilus.
• Другие существуют только для того, чтобы тратить место на диске, не имея реального описания того, для чего они предназначены. Несмотря на это, я должен установить для них значения, которые не являются ни фиксированными, ни тривиальными. Возможно, я должен просто установить их на случайные (то есть, не фиксированные) строки из Шекспира (то есть, не тривиальные).

Или еще лучше: для чего нужны другие поля?

Это куча бесполезных строк, кроме LVID .

Форма mkudffs:

• --lvid Указать идентификатор логического тома. Устанавливает данную строку в следующие поля:
  • Идентификатор логического тома в дескрипторе логического тома (см. Рисунок 15 в ECMA-167 )
  • Идентификатор логического тома в реализации Использование. (См. 2.2.7.2 в UDF 2.01 )
  • Идентификатор логического тома в дескрипторе набора файлов. (См. Рисунок 9 в ECMA-167 ) Дескриптор набора файлов. (См. Рисунок 9 в [ECMA-167] [5]).
    Идентификатор логического тома отображается в окнах как метка диска.
• --vid Указать идентификатор тома. Он устанавливает строку уступки в поле Идентификатор тома в Первичном дескрипторе тома. (См. Рис. 6 в ECMA-167 ). Максимальная длина 31 байт. Значение по умолчанию "Linux UDF".
• --vsid Указать идентификатор набора громкости. Он устанавливает данную строку в поле идентификатора набора томов в дескрипторе первичного тома. (См. Рис. 6 в ECMA-167 ). Максимальная длина 127 байт. Значение по умолчанию "Linux UDF".
  Volume Set Identifier может быть отредактирован некоторыми программами создания диска, такими как ImgBurn, MagicISO. Он указывает идентификацию набора томов, членом которого является том.
• --fsid Указать идентификатор набора файлов. Он устанавливает поле идентификатора набора файлов в дескрипторе набора файлов. (См. Рисунок 9 в ECMA-167 ). Максимальная длина 31 байт. Значение по умолчанию "Linux UDF".

Я думаю, что это полностью зависит от вас; Я бы сказал, что есть поля для поддержки корпоративных процессов. Одно из подходов, которое легко приходит на ум, - это использовать идентификатор набора томов для таких вещей, как «ежемесячное полное резервное копирование FOO, 2015-12», и тогда идентификатор тома может быть чем-то вроде «диск 1 из 42». Или, может быть, у вас на самом деле будет физический идентификатор, например, штрих-код, напечатанный на диске, и идентификатор тома может содержать его (так что вы можете идентифицировать диск, либо читая его в накопителе, либо указывая на него считывателем штрих-кода). ).

Я полагаю, что идентификатор набора файлов может быть полезен, когда вы помещаете кучу файлов в файловую систему, которые образуют некоторую логическую единицу («набор»), но они не образуют интуитивно «объем»; например, "Мэрайя Кэри. GIFS 1994-1998" или "Очерки средней школы Боба".

Логически говоря, все эти поля существуют для того, чтобы содержать данные, в которых некоторые члены (или члены) комитета, которые разработали и / или изменили стандарт, увидели необходимость. Тот факт, что кто-то считает, что это пустая трата места на диске, не означает, что на момент согласования стандарта не было одного или нескольких мнений по этому вопросу. Фактически, некоторые члены или члены комитета считали их достаточно полезными для той или иной цели, и они попали в стандарт. Я говорю, что все, что явно не определено в стандарте, открыто для интерпретации и, следовательно, может использоваться либо для любых целей, которые вы пожелаете, либо безопасно игнорировать до тех пор, пока оно не будет явно определено стандартом. С точки зрения разработки программного обеспечения, 'mkudffs' не нужно определять, для чего вы должны использовать эти поля,

Я думаю, что эти ценности ориентированы на другие спецификации, которые сами пытаются обобщить медиа-мн. В моем примере я буду ссылаться на Linux, но это не значит, что это не относится к Windows. Эти спецификации. там просто спрятаны

Запустите следующий cmd в Linux и посмотрите на вывод: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Базовый раздел данных" PARTUUID = "?"

/ dev / y: LABEL = "Linux" UUID = "?" TYPE = "ext4" PARTLABEL = "хранилище" PARTUUID = "?"

Как видите, для каждого есть 2 поля описания:

• раздел
• Файловая система на этом разделе

В обоих случаях первое - это удобочитаемое описание, а второе - описание машины. Как и в системе доменных имен (DNS), так как описание компьютера - UUID - должно быть уникальным. Таким образом, мы можем говорить о nx 2 x 2 полей данных для разделов. Но поскольку оптический носитель не разбивается на разделы, необработанный носитель считается самим разделом. Это означает, что всегда есть 2 x 2 = 4 атрибута. Давайте попробуем вписать свойства UDF в приведенный выше пример:

/ dev / x: LABEL = "LVID" UUID = "VID" TYPE = "UDF" PARTLABEL = "VSID" PARTUUID = "FSID"

Я часами искал и читал много статей, но не смог это проверить. Так что это всего лишь предположение. Но для LVID это обеспечено определением термина и испытанием. Linux и Windows, последняя с WinCDemu, используют это свойство в качестве метки для раздела. Что для оптических носителей является самой средой.

Это на самом деле подходит довольно аккуратно, но поднимает один вопрос. Есть дополнительное свойство UUID, и я склонен полагать, что это ошибка реализации некоторого вида. Потому что я когда-то читал в этой сети, что это было реализовано позже, потому что чел. не удалось смонтировать UDF-носитель по UUID. Таким образом, это могло быть неправильное понимание данных полей свойств. Я не знаю, куда помещается текущий UUID, но blkid читает это как UUID. Я не знаю, это драйвер UDF или проблема blkid. Может быть, кто-то пишет письмо с подсказкой соответствующему человеку / группе.