Яка різниця між ідентифікатором тома, ідентифікатором набору томів, логічним ідентифікатором томів та ідентифікатором набору файлів?

Я бачу, що mkudffsє варіанти для чотирьох різних ідентифікаторів: логічний том ( --lvid), том ( --vid), набір томів ( --vsid) та ідентифікатор набору файлів ( --fsid). Однак це не дає вказівки щодо того, що це означає.

Отже, я перейшов до специфікацій АДС. Починаючи з ISO / IEC 13346 aka 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 у СДС 2.01 )
  • Логічний ідентифікатор гучності в дескрипторі набору файлів. (Див. Рисунок 9 у ECMA-167 ) Дескриптор набору файлів. (Див. Рисунок 9 у [ECMA-167] [5]).
    Логічний ідентифікатор гучності, показаний у Windows як мітка диска.
• --vid Вкажіть ідентифікатор гучності. Він встановлює рядок подання в поле Ідентифікатор тому в первинному дескрипторі томів. (Див. Рисунок 6 у ECMA-167 ). Максимальна довжина 31 байт. Значення за замовчуванням "Linux UDF".
• --vsid Вкажіть ідентифікатор набору гучності. Він встановлює задану рядок у поле ідентифікатора набору томів у первинному дерипторі томів. (Див. Рисунок 6 у ECMA-167 ). Максимальна довжина 127 байт. Значення за замовчуванням "Linux UDF".
  Ідентифікатор набору томів може редагуватися деякими програмами для створення диска, такими як ImgBurn, MagicISO. Він задає ідентифікацію набору томів, членом якого є том.
• --fsid Вкажіть ідентифікатор набору файлів. Він встановлює поле Ідентифікатор набору файлів у Дескрипторі наборів файлів. (Див. Малюнок 9 у ECMA-167 ). Максимальна довжина 31 байт. Значення за замовчуванням "Linux UDF".

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

Я думаю, що ідентифікатор набору файлів може бути корисним, коли ви розміщуєте купу файлів у файловій системі, що утворюють певну логічну одиницю ("набір"), але вони інтуїтивно не утворюють "том"; наприклад, "Mariah Carey .gifs 1994-1998" або "нариси Боба про середню школу".

Логічно кажучи, ці поля існують, щоб містити дані, які потребує деякий член (або члени) комітету, який розробив та / або змінив стандарт. Тільки тому, що хтось думає, що це марно витрачаючи місце на диску, це не означає, що не було однієї чи декількох думок з цього приводу, коли стандарт був узгоджений. Насправді, хтось із членів комітету чи членів комітету вважав їх достатньо корисними для тієї чи іншої мети, що вони внесли до стандарту. Я кажу, що все, що не визначено явно в стандарті, є відкритим для тлумачення, і тому його можна використовувати або з будь-якою метою ви бажаєте, або безпечно ігнорувати до тих пір, поки це НЕ чітко визначено стандартом. З точки зору створення програмного забезпечення, "mkudffs" Не потрібно визначати, для чого слід використовувати ці поля,

Я думаю, що ці цінності орієнтуються на інші характеристики, які самі намагаються узагальнити медіа mngt. У своєму прикладі я буду посилатися на Linux, але це не означає, що це не стосується Windows. Ці характеристики. просто заховані там.

Запустіть наступний cmd на Linux і подивіться на вихід: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Основний розділ даних" PARTUUID = "?"

/ dev / y: LABEL = "Linux" UUID = "?" TYPE = "ext4" PARTLABEL = "зберігання" PARTUUID = "?"

Як бачите, для кожного є 2 поля опису:

• Перегородка
• FileSystem на цьому розділі

В обох випадках перший - це читаний для людини опис, а останній - опис машини. Так само, як і в системі доменних імен (DNS), оскільки опис машини - UUID - повинен бути унікальним. Таким чином, ми можемо говорити про nx 2 x 2 поля даних для розділів. Але, оскільки оптичний носій не розділяється, необроблений носій вважається самим розділом. Це означає, що завжди є 2 х 2 = 4 атрибути. Давайте спробуємо вписати властивості UDF у наведений вище приклад:

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

Я годинами шукав і читав багато статей, але не міг цього перевірити. Тож це лише припущення. Але для LVID це гарантується визначенням терміна та судовим шляхом. Linux та Windows, останні з WinCDemu, використовують цю властивість як мітку для розділу. Що для оптичних носіїв - саме середовище.

Це насправді підходить досить акуратно, але викликає одне питання. Існує додаткова властивість UUID, і я схильний вважати, що це помилка впровадження. Тому що я одного разу читав у цій мережі, що це було реалізовано пізніше, оскільки ppl. не вдалося змонтувати медіа UDF за допомогою UUID. Тож це може бути непорозуміння даних полів властивості. Я не знаю, куди ставиться поточний UUID, але blkid читає цей як UUID. Я не знаю, чи це проблема з драйвером UDF або blkid. Можливо, хтось пише листа з підказкою до відповідної особи / групи.