In UDF, qual è la differenza tra un identificatore di volume, un identificatore di set di volumi, un identificatore di volume logico e un identificatore di set di file?

Vedo che mkudffsha opzioni per quattro diversi identificatori: il volume logico ( --lvid), il volume ( --vid), il volume set ( --vsid) e l'identificatore del set di file ( --fsid). Tuttavia, non fornisce indicazioni su cosa significhino.

Quindi, sono andato alle specifiche UDF. A partire da ISO / IEC 13346 aka ECMA-167 , trovo che:

10.1.4 Identificatore di volume (BP 24)

Questo campo deve specificare un'identificazione del volume.

14.1.10 Identificatore volume logico (BP 112)

Questo campo deve specificare un'identificazione del volume logico su cui è registrato il set di file.

14.1.12 Identificatore set file (BP 304)

Questo campo deve specificare un'identificazione del set di file descritto da questo descrittore del set di file.

Bene, è stato utile.

Quindi, ho provato OSTA UDF Spec 1.02 , poiché questa è la versione UDF che sto cercando di generare. Non ha aiutato molto (anche se mi ha messo in guardia contro "valori fissi o banali").

Ho provato la specifica UDF 1.50 che mi dice ulteriormente - nel §4.1 - che prima di visualizzare quei valori, è necessario applicare una trasformazione specifica del sistema operativo usando gli algoritmi descritti nel §4.1.2.1. Naturalmente, la sezione successiva dopo §4.1 è §4.2, quindi buona fortuna. Inoltre, LogicalVolumeIdentifier è "estremamente importante per l'identificazione del volume logico quando sono presenti più supporti all'interno di un jukebox. Il nome è in genere ciò che viene visualizzato all'utente."

Quindi, provo la specifica UDF 2.01 e ora so che almeno adesso hanno capito che è 4. 2 .2.1, che esiste, ma non aiuta (si tratta di cose come set di caratteri).

Quindi, per quanto posso dire:

• L'identificatore del volume logico è ciò che viene visualizzato all'utente (probabilmente solo jukebox). Quindi dovrebbe essere impostato su qualcosa di significativo, ad esempio il titolo del disco. Presumo che questo sia il titolo del disco che verrà visualizzato su Windows, Mac OS o Nautilus.
• Gli altri esistono solo per sprecare spazio sul disco, senza una vera descrizione di ciò a cui sono destinati. Nonostante ciò, dovrei impostarli su valori che non sono né fissi né banali. Forse, dovrei semplicemente impostarli su linee casuali (cioè non fisse) da Shakespeare (cioè, non banali).

O meglio ancora: a cosa servono gli altri campi?

Questi sono gruppi di stringhe non utili, tranne LVID .

Forma mkudffs:

• --lvid Specifica l'identificatore del volume logico. Imposta la stringa assegnata ai seguenti campi:
  • Identificatore del volume logico nel descrittore del volume logico (vedere la Figura 15 in ECMA-167 )
  • Identificatore di volume logico nell'uso dell'implementazione. (Vedi 2.2.7.2 in UDF 2.01 )
  • Identificatore volume logico nel descrittore del set di file. (Vedere la Figura 9 in ECMA-167 ) Descrittore set di file. (Vedi figura 9 in [ECMA-167] [5]).
    Identificatore di volume logico mostrato in Windows come etichetta del disco.
• --vid Specifica l'identificatore del volume. Imposta la stringa givend sul campo Identificatore volume nel Descrittore volume primario. (Vedi figura 6 in ECMA-167 ). Lunghezza massima 31 byte. Valore predefinito "Linux UDF".
• --vsid Specifica l'identificatore del set di volumi. Imposta la stringa data nel campo identificatore della serie di volumi nel Desriptor del volume primario. (Vedi figura 6 in ECMA-167 ). Lunghezza massima 127 byte. Valore predefinito "Linux UDF".
  Volume Set Identifier può essere modificato da alcuni programmi di authoring del disco come ImgBurn, MagicISO. Specifica un'identificazione del set di volumi di cui il volume è membro.
• --fsid Specifica l'identificatore del set di file. Imposta il campo Identificatore set file nel descrittore set file. (Vedi figura 9 in ECMA-167 ). Lunghezza massima 31 byte. Valore predefinito "Linux UDF".

Penso che dipendano completamente da te; Direi che i campi sono lì per supportare i processi aziendali. Un uso che viene subito in mente è usare l'identificatore del volume impostato per cose come "backup completo mensile di FOO, 2015-12", e l'identificatore del volume potrebbe quindi essere qualcosa come "disco 1 di 42". O forse avrai effettivamente un identificatore fisico, ad esempio un codice a barre, stampato sul disco e l'identificatore del volume può trattenerlo (in modo da poter identificare il disco leggendolo in un'unità o puntando un lettore di codici a barre su di esso ).

Immagino che l'identificatore del set di file possa essere utile quando si inseriscono un mucchio di file nel filesystem che formano una sorta di unità logica (un "set"), ma non formano in modo intuitivo un "volume"; per esempio, "Mariah Carey .gifs 1994-1998" o "Saggi di liceo di Bob".

Logicamente parlando, esistono tutti quei campi che contengono dati di cui alcuni membri (o membri) del comitato che hanno sviluppato e / o modificato lo standard hanno ritenuto necessario. Solo perché qualcuno pensa che sia uno spreco di spazio sul disco non significa che non ci siano state una o più opinioni sulla questione quando lo standard è stato concordato. In effetti, alcuni membri del comitato li hanno ritenuti abbastanza utili per un motivo o per un altro da farli entrare nello standard. Dico che tutto ciò che non è definito in modo esplicito in uno standard è suscettibile di interpretazione e pertanto può essere utilizzato per qualsiasi scopo desiderato o ignorato in modo sicuro fino a quando non viene esplicitamente definito dallo standard. Dal punto di vista della creazione di software, "mkudffs" non ha bisogno di definire per cosa utilizzare questi campi,

Penso che questi valori si orientino su altre specifiche, che a loro volta cercano di generalizzare i media. Nel mio esempio mi riferirò a Linux ma questo non significa che non si applicherebbe a Windows. Quelle specifiche. sono appena nascosti lì.

Esegui il seguente cmd su Linux e osserva l'output: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Partizione dati di base" PARTUUID = "?"

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

Come puoi vedere, ci sono 2 campi descrittivi per ogni:

• Partizione
• FileSystem su quella partizione

In entrambi i casi, la prima è la descrizione leggibile dall'uomo e la seconda la descrizione della macchina. Proprio come nel Domain Name System (DNS), poiché la descrizione della macchina - l'UUID - richiede di essere unica. Quindi possiamo parlare di nx 2 x 2 campi dati, per le partizioni. Tuttavia, poiché il supporto ottico non viene partizionato, il supporto non elaborato conta come partizione stessa. Ciò significa che ci sono sempre 2 x 2 = 4 attributi. Proviamo ad adattare le proprietà UDF nell'esempio sopra:

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

Ho cercato per ore e letto molti articoli, ma non sono riuscito a verificarlo. Quindi questo è solo un presupposto. Ma per LVID è assicurato dalla definizione del termine e dal processo. Linux e Windows, quest'ultimo con WinCDemu, usano questa proprietà come etichetta per la partizione. Che, per i supporti ottici, è il mezzo stesso.

In realtà si adatta abbastanza bene, ma solleva una domanda. Esiste una proprietà UUID aggiuntiva e tendo a credere che si tratti di un errore di implementazione di qualche tipo. Perché una volta ho letto su questa rete, che questo è stato implementato in seguito, perché ppl. non sono stati in grado di montare supporti UDF tramite UUID. Quindi potrebbe essere stato un fraintendimento dei campi di proprietà dati. Non so dove venga messo l'UUID corrente, ma blkid legge questo come UUID. Non so se si tratta di un driver UDF o di un problema blkid. Forse qualcuno scrive una mail con un suggerimento alla persona / al gruppo corrispondente.