No UDF, qual é a diferença entre um identificador de volume, um identificador de conjunto de volumes, um identificador de volume lógico e um identificador de conjunto de arquivos?

Question

Vejo que mkudffs tem opções para quatro identificadores diferentes: o volume lógico ( --lvid ), o volume ( --vid ), o volume definido ( --vsid ) e o identificador do conjunto de arquivos ( --fsid ). No entanto, não dá nenhuma orientação sobre o que isso significa.

Então, eu fui para as especificações do UDF. Começando com o ISO / IEC 13346, também conhecido como ECMA-167 , acho que :

10.1.4 Volume Identifier (BP 24)

This field shall specify an identification of the volume.

14.1.10 Logical Volume Identifier (BP 112)

This field shall specify an identification of the logical volume on which the file set is recorded.

14.1.12 File Set Identifier (BP 304)

This field shall specify an identification of the file set described by this File Set Descriptor.

Bem, isso foi útil.

Então, eu tentei a Especificação OSTA UDF 1.02 , como essa é a versão do UDF que eu sou tentando gerar. Não ajudou muito (embora tenha me alertado contra "valores fixos ou triviais").

Eu tentei a especificação UDF 1.50 que mais me diz - em §4.1 - que antes de exibir esses valores, que uma transformação específica do sistema operacional usando algoritmos descritos em §4.1.2.1 deve ser aplicada. É claro que a próxima seção após o §4.1 é o §4.2, então boa sorte nisso. Além disso, o LogicalVolumeIdentifier é "extremamente importante na identificação do volume lógico quando várias mídias estão presentes em uma jukebox. O nome é tipicamente o que é exibido para o usuário".

Então, eu tento a especificação da UDF 2.01 , e agora eu sei que agora pelo menos eles Eu percebi que é 4. 2 .2.1, que existe, mas não ajuda (lida com coisas como conjuntos de caracteres).

Então, tanto quanto eu posso dizer:

• O Identificador de Volume Lógico é o que é exibido para o usuário (possivelmente apenas para jukeboxes). Por isso, deve ser definido como algo significativo, por exemplo, o título do disco. Eu assumo que este é o título do disco que o Windows, Mac OS ou Nautilus exibiria.
• Os outros existem apenas para desperdiçar espaço no disco, não tendo uma descrição real do que eles são. Apesar disso, eu deveria colocá-los em valores que não são nem fixos nem triviais. Possivelmente, eu deveria apenas configurá-las para linhas aleatórias (isto é, não fixas) de Shakespeare (isto é, não triviais).

Ou melhor: quais são os outros campos?

    

Answer 1

Estas são muitas cadeias não úteis, exceto LVID .

Forma mkudffs:

• - lvid Especifique o identificador de volume lógico. Define a string dada para os seguintes campos:
  • Identificador de volume lógico no descritor de volume lógico (ver Figura 15 em ECMA- 167 )
  • Identificador de volume lógico no uso da implementação. (Ver 2.2.7.2 em UDF 2.01 )
  • Identificador do volume lógico no descritor do conjunto de arquivos. (Veja a Figura 9 em ECMA-167 ) Descritor do Conjunto de Arquivos. (Veja a Figura 9 no [ECMA-167] [5]).
    Identificador de Volume Lógico mostrado no Windows como rótulo de disco.
• - vid Especifique o identificador de volume. Define a string givend para o campo Identificador de Volume no Descritor de Volume Primário. (Veja a Figura 6 em ECMA-167 ). Comprimento máximo 31 bytes. Valor padrão "Linux UDF".
• - vsid Especifique o identificador do conjunto de volumes. Ele define a string dada para o campo do identificador do conjunto de volumes no Desriptor de Volume Primário. (Veja a Figura 6 em ECMA-167 ). Comprimento máximo 127 bytes. Valor padrão "Linux UDF".
  O Volume Set Identifier pode ser editado por alguns programas de criação de disco como o ImgBurn, MagicISO. Ele especifica uma identificação do conjunto de volumes do qual o volume é um membro.
• - fsid Especifica o identificador do conjunto de arquivos. Define o campo Identificador do Conjunto de Arquivos no Descritor do Conjunto de Arquivos. (Veja a Figura 9 em ECMA-167 ). Comprimento máximo 31 bytes. Valor padrão "Linux UDF".

Answer 2

Eu acho que isso é completamente com você; Eu diria que os campos estão lá para suportar processos corporativos. Um uso que vem prontamente à mente é usar o identificador de conjunto de volume para coisas como "backup completo mensal de FOO, 2015-12", e o identificador de volume poderia ser algo como "disco 1 de 42". Ou talvez você realmente tenha um identificador físico, por exemplo um código de barras, impresso no disco, e o identificador de volume pode conter isso (para que você possa identificar o disco lendo-o em uma unidade ou apontando um leitor de código de barras para ele).

Eu imagino que o identificador do conjunto de arquivos pode ser útil quando você está colocando um monte de arquivos no sistema de arquivos que formam alguma forma de unidade lógica (um "conjunto"), mas eles não formam intuitivamente um "volume"; por exemplo, "Mariah Carey .gifs 1994-1998" ou "Bob's high school essays".

    

Answer 3

Logicamente falando, todos os campos existem para conter dados que algum membro (ou membros) do comitê que desenvolveu e / ou modificou a norma considerou necessário. Só porque alguém acha que é um desperdício de espaço no disco não significa que não houve uma ou mais opiniões sobre o assunto quando o padrão foi acordado. De fato, alguns membros ou membros do comitê consideraram-nos úteis o suficiente para um propósito ou outro, que fizeram o caminho para o padrão. Eu digo que qualquer coisa não explicitamente definida em um padrão é aberta à interpretação e, portanto, pode ser usada para qualquer propósito que você desejar ou seguramente ignorado até que seja explicitamente definido pelo padrão. Do ponto de vista de criação de software, 'mkudffs' Não precisa definir para que você deve usar esses campos, apenas forneça um mecanismo para permitir que você use (ou use de forma inadequada a perspectiva) como quiser, cumprindo assim o padrão .

    

Answer 4

Eu acho que esses valores se orientam em outras especificações, que eles mesmos tentam generalizar a mídia. No meu exemplo, vou me referir ao Linux, mas isso não significa que não se aplicaria ao Windows. Essas especificações estão apenas escondidos lá.

Execute o seguinte cmd no Linux e observe a saída: blkid

/dev/x: LABEL="Windows" UUID="?" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="?"

/dev/y: LABEL="Linux" UUID="?" TYPE="ext4" PARTLABEL="storage" PARTUUID="?"

Como você pode ver, existem dois campos de descrição para cada:

• Partição
• FileSystem nessa partição

Em ambos os casos, o primeiro é a descrição legível por humanos e o segundo a descrição da máquina. Assim como no sistema de nomes de domínio (DNS), desde a descrição da máquina - o UUID - requer ser exclusivo. Então podemos falar sobre n x 2 x 2 campos de dados, para partições. Mas, como a mídia ótica não é particionada, a mídia não processada conta como a própria partição. O que significa que existem 2 x 2 = 4 atributos, sempre. Vamos tentar encaixar as propriedades da UDF no exemplo acima:

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

Eu pesquisei por horas e li muitos artigos, mas não consegui verificar isso. Então isso é apenas uma suposição. Mas para o LVID é assegurado pela definição do termo e pelo julgamento. Linux e Windows, este último com WinCDemu, usam essa propriedade como rótulo para a partição. Que, para mídia ótica, é o próprio meio.

Na verdade, ele se encaixa bem, mas levanta uma questão. Há uma propriedade extra do UUID e estou pensando que isso é um erro de implementação de algum tipo. Porque eu li uma vez nesta rede, que isso foi implementado mais tarde, porque ppl. não foi possível montar mídia UDF pelo UUID. Então, pode ter sido um mal-entendido dos campos de propriedade fornecidos. Eu não sei onde o UUID atual está sendo colocado, mas blkid lê este como UUID. Eu não sei se isso é um driver UDF ou problema blkid. Talvez alguém escreva um email com uma sugestão para a pessoa / grupo correspondente.