En UDF, ¿cuál es la diferencia entre un identificador de volumen, un identificador de conjunto de volumen, un identificador de volumen lógico y un identificador de conjunto de archivos?

Veo que mkudffstiene opciones para cuatro identificadores diferentes: el volumen lógico ( --lvid), el volumen ( --vid), el conjunto de volúmenes ( --vsid) y el identificador del conjunto de archivos ( --fsid). Sin embargo, no ofrece orientación sobre lo que significan.

Entonces, fui a las especificaciones UDF. Comenzando con ISO / IEC 13346, también conocido como ECMA-167 , encuentro que:

10.1.4 Identificador de volumen (BP 24)

Este campo debe especificar una identificación del volumen.

14.1.10 Identificador de volumen lógico (BP 112)

Este campo especificará una identificación del volumen lógico en el que se graba el conjunto de archivos.

14.1.12 Identificador de conjunto de archivos (BP 304)

Este campo especificará una identificación del conjunto de archivos descrito por este Descriptor de conjunto de archivos.

Bueno, eso fue útil.

Entonces, probé la OSTA UDF Spec 1.02 , ya que esa es la versión UDF que estoy tratando de generar. No ayudó mucho (aunque me advirtió contra "valores fijos o triviales").

Intenté con la especificación UDF 1.50 que me dice además, en §4.1, que antes de mostrar esos valores, se debe aplicar una transformación específica del sistema operativo utilizando los algoritmos descritos en §4.1.2.1. Por supuesto, la siguiente sección después de §4.1 es §4.2, así que buena suerte en eso. Además, LogicalVolumeIdentifier es "extremadamente importante en la identificación de volumen lógico cuando hay múltiples medios dentro de una máquina de discos. El nombre suele ser lo que se muestra al usuario".

Entonces, pruebo la especificación UDF 2.01 , y ahora sé que al menos se han dado cuenta de que es 4. 2 .2.1, que existe, pero no ayuda (se trata de cosas como conjuntos de caracteres).

Entonces, hasta donde puedo decir:

• El identificador de volumen lógico es lo que se muestra al usuario (posiblemente solo sean jukeboxes). Por lo tanto, debe establecerse en algo significativo, por ejemplo, el título del disco. Supongo que este es el título del disco que Windows, Mac OS o Nautilus mostrarían.
• Los otros solo existen para desperdiciar espacio en el disco y no tienen una descripción real de para qué sirven. A pesar de eso, debería establecerlos en valores que no sean fijos ni triviales. Posiblemente, debería establecerlos en líneas aleatorias (es decir, no fijas) de Shakespeare (es decir, no triviales).

O, mejor aún: ¿para qué sirven los otros campos?

Estas son un montón de cadenas no útiles, excepto LVID .

Forma mkudffs:

• --lvid Especifica el identificador de volumen lógico. Establece la cadena dada en los siguientes campos:
  • Identificador de volumen lógico en el Descriptor de volumen lógico (Ver Figura 15 en ECMA-167 )
  • Identificador de volumen lógico en el uso de implementación. (Ver 2.2.7.2 en UDF 2.01 )
  • Identificador de volumen lógico en el descriptor de conjunto de archivos. (Ver Figura 9 en ECMA-167 ) Descriptor de conjunto de archivos. (Ver Figura 9 en [ECMA-167] [5]).
    Identificador de volumen lógico que se muestra en Windows como etiqueta de disco.
• --vid Especifica el identificador de volumen. Establece la cadena de entrega en el campo Identificador de volumen en el Descriptor de volumen primario. (Ver Figura 6 en ECMA-167 ). Longitud máxima 31 bytes. Valor predeterminado "Linux UDF".
• --vsid Especifica el identificador del conjunto de volúmenes. Establece la cadena dada en el campo identificador del conjunto de volumen en el Descriptor de volumen primario. (Ver Figura 6 en ECMA-167 ). Longitud máxima 127 bytes. Valor predeterminado "Linux UDF".
  Volume Set Identifier puede ser editado por algunos programas de creación de discos como ImgBurn, MagicISO. Especifica una identificación del conjunto de volúmenes del que es miembro el volumen.
• --fsid Especifica el identificador del conjunto de archivos. Establece el campo Identificador de conjunto de archivos en el Descriptor de conjunto de archivos. (Ver Figura 9 en ECMA-167 ). Longitud máxima 31 bytes. Valor predeterminado "Linux UDF".

Creo que estos son completamente de usted; Yo diría que los campos están ahí para soportar procesos empresariales. Un uso que viene a la mente es usar el identificador de conjunto de volúmenes para cosas como "copia de seguridad completa mensual de FOO, 2015-12", y el identificador de volumen podría ser algo así como "disco 1 de 42". O tal vez realmente tenga un identificador físico, por ejemplo, un código de barras, impreso en el disco, y el identificador de volumen puede contenerlo (para que pueda identificar el disco ya sea al leerlo en una unidad o al apuntarlo con un lector de código de barras) )

Me imagino que el identificador del conjunto de archivos podría ser útil cuando está colocando un montón de archivos en el sistema de archivos que forman algún tipo de unidad lógica (un "conjunto"), pero no forman intuitivamente un "volumen"; por ejemplo, "Mariah Carey .gifs 1994-1998" o "Ensayos de la escuela secundaria de Bob".

Lógicamente hablando, todos esos campos existen para contener datos que algunos miembros (o miembros) del comité que desarrollaron y / o modificaron el estándar vieron la necesidad. El hecho de que alguien piense que es una pérdida de espacio en el disco no significa que no hubo una o más opiniones sobre el tema cuando se acordó el estándar. De hecho, algunos miembros o miembros del comité los consideraron lo suficientemente útiles para un propósito u otro como para llegar a la norma. Digo que cualquier cosa que no esté explícitamente definida en un estándar está abierta a interpretación y, por lo tanto, puede usarse para cualquier propósito que desee o ignorarse con seguridad hasta el momento en que el estándar lo defina explícitamente. Desde una perspectiva de autoría de software, 'mkudffs' no necesita definir para qué debe usar estos campos,

Creo que estos valores se orientan a otras especificaciones, que ellos mismos intentan generalizar los medios de comunicación. En mi ejemplo, me referiré a Linux, pero esto no significa que no se aplicaría a Windows. Esas especificaciones. están escondidos allí

Ejecute el siguiente cmd en Linux y mire la salida: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Partición de datos básicos" PARTUUID = "?"

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

Como puede ver, hay 2 campos de descripción para cada:

• Dividir
• FileSystem en esa partición

En ambos casos, el primero es la descripción legible por humanos y el segundo la descripción de la máquina. Al igual que en el Sistema de nombres de dominio (DNS), ya que la descripción de la máquina, el UUID, debe ser única. Entonces podemos hablar de nx 2 x 2 campos de datos, para particiones. Pero, dado que los medios ópticos no se particionan, los medios en bruto cuentan como partición en sí. Lo que significa que hay 2 x 2 = 4 atributos, siempre. Intentemos ajustar las propiedades UDF en el ejemplo anterior:

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

Busqué durante horas y leí muchos artículos, pero no pude verificar esto. Entonces esto es solo una suposición. Pero para el LVID está asegurado por definición del término y por juicio. Linux y Windows, este último con WinCDemu, usan esta propiedad como etiqueta para la partición. Que, para los medios ópticos, es el medio en sí.

En realidad, se ajusta bastante bien, pero plantea una pregunta. Hay una propiedad adicional de UUID y tiendo a creer que se trata de un error de implementación de algún tipo. Porque una vez leí en esta red, que esto se implementó más tarde, porque ppl. no se pudieron montar medios UDF por UUID. Por lo tanto, puede haber sido un malentendido de los campos de propiedad dados. No sé dónde se está poniendo el UUID actual, pero blkid lee este como UUID. No sé si este es un controlador UDF o un problema blkid. Tal vez alguien escriba un correo con una pista a la persona / grupo correspondiente.