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

Vejo que mkudffstem opções para quatro identificadores diferentes: o volume lógico ( --lvid), o volume ( --vid), o conjunto de volumes ( --vsid) e o identificador de conjunto de arquivos ( --fsid). No entanto, não fornece orientação para o que esses significam.

Então, eu fui para as especificações da UDF. Começando com ISO / IEC 13346 aka ECMA-167 , eu acho que:

10.1.4 Identificador de volume (BP 24)

Este campo deve especificar uma identificação do volume.

14.1.10 Identificador lógico de volume (BP 112)

Este campo deve especificar uma identificação do volume lógico no qual o conjunto de arquivos é gravado.

14.1.12 Identificador do conjunto de arquivos (BP 304)

Este campo deve especificar uma identificação do conjunto de arquivos descrito por este Descritor de Conjunto de Arquivos.

Bem, isso foi útil.

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

Tentei a especificação UDF 1.50, que me diz ainda - no §4.1 - que, antes de exibir esses valores, uma transformação específica do SO usando os algoritmos descritos no §4.1.2.1 deve ser aplicada. Obviamente, a próxima seção após o §4.1 é §4.2, portanto, 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 geralmente é o que é exibido ao usuário".

Então, eu tento a especificação UDF 2.01 , e agora eu sei que a essa altura, pelo menos, eles já perceberam que é 4. 2 .2.1, o que existe, mas não ajuda (ele 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 jukeboxes). Portanto, deve ser definido como algo significativo, por exemplo, o título do disco. Presumo que este seja o título do disco que o Windows, Mac OS ou Nautilus exibiriam.
• Os outros existem apenas para desperdiçar espaço no disco, sem uma descrição real do seu objetivo. Apesar disso, devo defini-los para valores que não são fixos nem triviais. Possivelmente, eu deveria apenas configurá-las para linhas aleatórias (ou seja, não fixas) de Shakespeare (ou seja, não triviais).

Ou, melhor ainda: para que servem os outros campos?

Essas são várias seqüências não úteis, exceto LVID .

Forma mkudffs:

• --lvid Especifique o identificador de volume lógico. Ele define a sequência especificada para os seguintes campos:
  • Identificador de volume lógico no descritor de volume lógico (consulte a Figura 15 no ECMA-167 )
  • Identificador de volume lógico no uso da implementação. (Ver 2.2.7.2 no UDF 2.01 )
  • Identificador de volume lógico no descritor de conjunto de arquivos. (Veja a Figura 9 no ECMA-167 ) Descritor de conjunto de arquivos. (Veja a Figura 9 em [ECMA-167] [5]).
    Identificador de volume lógico mostrado nas janelas como etiqueta do disco.
• --vid Especifique o identificador de volume. Ele define a cadeia de caracteres givend no campo Identificador de volume no Descritor de volume primário. (Veja a Figura 6 na ECMA-167 ). Comprimento máximo 31 bytes. Valor padrão "Linux UDF".
• --vsid Especifique o identificador do conjunto de volumes. Ele define a sequência especificada no campo identificador do conjunto de volumes no Desriptor de volume primário. (Veja a Figura 6 na ECMA-167 ). Comprimento máximo 127 bytes. Valor padrão "Linux UDF".
  O Identificador de conjunto de volumes pode ser editado por alguns programas de criação de disco como ImgBurn, MagicISO. Ele especifica uma identificação do conjunto de volumes do qual o volume é membro.
• --fsid Especifique o identificador do conjunto de arquivos. Ele define o campo Identificador do conjunto de arquivos no Descritor do conjunto de arquivos. (Veja a Figura 9 no ECMA-167 ). Comprimento máximo 31 bytes. Valor padrão "Linux UDF".

Eu acho que isso depende completamente de você; Eu diria que os campos existem para dar suporte aos processos corporativos. Um uso que vem à mente é usar o identificador do conjunto de volumes para coisas como "backup completo mensal do FOO, 2015-12", e o identificador de volume pode ser algo como "disco 1 de 42". Ou talvez você tenha um identificador físico, por exemplo, um código de barras, impresso no disco, e o identificador de volume possa mantê-lo (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 possa ser útil quando você estiver colocando um monte de arquivos no sistema de arquivos que formam algum tipo de unidade lógica (um "conjunto"), mas eles não formam intuitivamente um "volume"; por exemplo, "Mariah Carey .gifs 1994-1998" ou "ensaios da escola secundária de Bob".

Logicamente falando, todos esses campos existem para conter dados que algum membro (ou membros) do comitê que desenvolveu e / ou modificou o padrão considerou necessário. Só porque alguém pensa que é um desperdício de espaço no disco não significa que não havia uma ou mais opiniões sobre o assunto quando o padrão foi acordado. De fato, algum membro ou membros do comitê os consideraram úteis o suficiente para um propósito ou outro que eles fizeram lá dentro do padrão. Eu digo que qualquer coisa que não esteja explicitamente definida em um padrão está aberta à interpretação e, portanto, pode ser usada para qualquer finalidade que você desejar ou ignorada com segurança até que seja explicitamente definido pelo padrão. De uma perspectiva de criação de software, 'mkudffs' não precisa definir para que você deve usar esses campos,

Eu acho que esses valores se orientam em outras especificações, que 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 = "Partição de dados básica" PARTUUID = "?"

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

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

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

Nos dois casos, o primeiro é a descrição legível por humanos e o último a descrição da máquina. Assim como no sistema de nomes de domínio (DNS), já que a descrição da máquina - o UUID - precisa ser única. Então, podemos falar sobre campos de dados nx 2 x 2, para partições. Mas, como a mídia ótica não é particionada, a mídia bruta conta como partição em si. O que significa que existem 2 x 2 = 4 atributos, sempre. Vamos tentar ajustar as propriedades UDF no exemplo acima:

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

Pesquisei horas e li muitos artigos, mas não consegui verificar isso. Portanto, isso é apenas uma suposição. Mas, para o LVID, isso é garantido por definição do termo e por julgamento. Linux e Windows, este último com WinCDemu, usa essa propriedade como rótulo para a partição. Qual, para mídia ótica, é o próprio meio.

Na verdade, ele se encaixa muito bem, mas levanta uma questão. Há uma propriedade UUID extra e estou tendendo a acreditar que este é um erro de implementação de algum tipo. Porque eu li uma vez nesta rede, que isso foi implementado mais tarde, porque pessoas. não foram capazes de montar mídia UDF pelo UUID. Portanto, pode ter sido um mal-entendido dos campos de propriedades fornecidos. Não sei onde o UUID atual está sendo colocado, mas o blkid lê esse como UUID. Não sei se este é um problema de driver UDF ou blkid. Talvez alguém escreva uma mensagem com uma dica para a pessoa / grupo correspondente.