Was ist in UDF der Unterschied zwischen einer Volume-ID, einer Volume-Set-ID, einer logischen Volume-ID und einer File-Set-ID?

Ich sehe, dass mkudffses Optionen für vier verschiedene Bezeichner gibt: den logischen Datenträger ( --lvid), den Datenträger ( --vid), den Datenträgersatz ( --vsid) und den Dateisatzbezeichner ( --fsid). Es gibt jedoch keine Anleitung, was diese bedeuten.

Also ging ich zu den UDF-Spezifikationen. Ausgehend von ISO / IEC 13346, auch bekannt als ECMA-167 , finde ich Folgendes:

10.1.4 Volume Identifier (BP 24)

In diesem Feld muss eine Identifizierung des Volumens angegeben werden.

14.1.10 Logical Volume Identifier (BP 112)

In diesem Feld wird eine Identifikation des logischen Datenträgers angegeben, auf dem der Dateisatz aufgezeichnet ist.

14.1.12 Dateigruppenkennung (BP 304)

In diesem Feld muss eine Identifikation des von diesem Dateisatz-Deskriptor beschriebenen Dateisatzes angegeben werden.

Nun, das war nützlich.

Also habe ich die OSTA UDF Spec 1.02 ausprobiert , da dies die UDF-Version ist, die ich zu generieren versuche. Es hat nicht viel geholfen (hat mich aber vor "festen oder trivialen Werten" gewarnt).

Ich habe die UDF 1.50-Spezifikation ausprobiert, aus der hervorgeht, dass vor dem Anzeigen dieser Werte eine betriebssystemspezifische Transformation unter Verwendung der in §4.1.2.1 beschriebenen Algorithmen angewendet werden muss. Natürlich ist der nächste Abschnitt nach §4.1 §4.2, also viel Glück damit. Außerdem ist der LogicalVolumeIdentifier "äußerst wichtig für die Identifizierung logischer Volumes, wenn mehrere Medien in einer Jukebox vorhanden sind. Der Name wird normalerweise dem Benutzer angezeigt."

Also versuche ich , die UDF 2.01 - Spezifikation , und jetzt weiß ich, dass mittlerweile zumindest haben sie realisiert , es ist 4. 2 .2.1, die es gar, aber nicht hilft (es handelt sich um Sachen wie Zeichensätze).

Soweit ich das beurteilen kann:

• Der Logical Volume Identifier ist das, was dem Benutzer angezeigt wird (möglicherweise nur Jukeboxen). Also sollte es auf etwas Sinnvolles eingestellt sein, zB den Disc-Titel. Ich gehe davon aus, dass dies der Disc-Titel ist, den Windows, Mac OS oder Nautilus anzeigen würden.
• Die anderen sind nur dazu da, Speicherplatz auf der CD zu verschwenden, da sie keine genaue Beschreibung des Verwendungszwecks haben. Trotzdem sollte ich sie auf Werte setzen, die weder fest noch trivial sind. Möglicherweise sollte ich sie nur auf zufällige (dh nicht feste) Zeilen von Shakespeare setzen (dh nicht trivial).

Oder noch besser: Wozu dienen die anderen Bereiche?

Dies sind einige nicht nützliche Zeichenfolgen, mit Ausnahme von LVID .

Form mkudffs:

• --lvid Geben Sie die logische Datenträgerkennung an. Die angegebene Zeichenfolge wird auf die folgenden Felder gesetzt:
  • Logical Volume Identifier im Logical Volume Descriptor (siehe Abbildung 15 in ECMA-167 )
  • Logical Volume Identifier in der Implementation Use. (Siehe 2.2.7.2 in UDF 2.01 )
  • Logical Volume Identifier im File Set Descriptor. (Siehe Abbildung 9 in ECMA-167 ) Dateigruppendeskriptor. (Siehe Abbildung 9 in [ECMA-167] [5]).
    Logical Volume Identifier wird in Windows als Datenträgerbezeichnung angezeigt.
• --vid Geben Sie die Datenträgerkennung an. Es setzt givend string auf das Feld Volume Identifier im Primary Volume Descriptor. (Siehe Abbildung 6 in ECMA-167 ). Maximale Länge 31 Bytes. Standardwert "Linux UDF".
• --vsid Geben Sie die Volume-Set- ID an . Die angegebene Zeichenfolge wird in das Feld "Volume Set Identifier" im primären Volume Desriptor eingefügt. (Siehe Abbildung 6 in ECMA-167 ). Maximale Länge 127 Bytes. Standardwert "Linux UDF".
  Volume Set Identifier kann von einigen Disk Authoring-Programmen wie ImgBurn, MagicISO bearbeitet werden. Es gibt eine Identifikation des Volume-Sets an, zu dem das Volume gehört.
• --fsid Geben Sie die Dateigruppen- ID an . Hiermit wird das Feld Dateigruppenkennung im Dateigruppendeskriptor festgelegt. (Siehe Abbildung 9 in ECMA-167 ). Maximale Länge 31 Bytes. Standardwert "Linux UDF".

Ich denke, das liegt ganz bei Ihnen. Ich würde sagen, die Felder dienen zur Unterstützung von Unternehmensprozessen. Eine Verwendung, die leicht in den Sinn kommt, ist die Verwendung der Volume-Set-Kennung für Dinge wie "monatliches vollständiges Backup von FOO, 2015-12", und die Volume-Kennung könnte dann so etwas wie "Datenträger 1 von 42" sein. Oder Sie haben tatsächlich eine physische Kennung, z. B. einen Barcode, auf der Festplatte gedruckt, und die Datenträgerkennung kann diese enthalten (sodass Sie die Festplatte identifizieren können, indem Sie sie in ein Laufwerk einlesen oder indem Sie einen Barcode-Leser darauf richten ).

Ich stelle mir vor, dass die Dateigruppen-ID nützlich sein könnte, wenn Sie eine Reihe von Dateien in das Dateisystem einfügen, die eine Art logische Einheit bilden (eine "Menge"), aber nicht intuitiv ein "Volume" bilden. Zum Beispiel "Mariah Carey .gifs 1994-1998" oder "Bob's High School Essays".

Logischerweise enthalten alle Felder Daten, die von einem Mitglied (oder Mitgliedern) des Ausschusses, der den Standard entwickelt und / oder geändert hat, benötigt wurden. Nur weil jemand denkt, dass es eine Verschwendung von Speicherplatz auf der Festplatte ist, heißt das nicht, dass es zu dem Zeitpunkt, als der Standard vereinbart wurde, keine oder mehrere Meinungen zu diesem Thema gab. Tatsächlich hielten einige Mitglieder des Komitees sie für den einen oder anderen Zweck für nützlich genug, um dort den Weg in den Standard zu finden. Ich sage, dass alles, was in einer Norm nicht explizit definiert ist, interpretationsfähig ist und daher entweder für den von Ihnen gewünschten Zweck verwendet oder ignoriert werden kann, bis es in der Norm explizit definiert ist. Aus Sicht der Softwareerstellung muss 'mkudffs' nicht definieren, wofür Sie diese Felder verwenden sollen.

Ich denke, diese Werte orientieren sich an anderen Spezifikationen, die sie selbst zu verallgemeinern versuchen. In meinem Beispiel beziehe ich mich auf Linux, aber das bedeutet nicht, dass es nicht auf Windows zutrifft. Diese Angaben. sind nur dort versteckt.

Führen Sie den folgenden Befehl unter Linux aus und sehen Sie sich die Ausgabe an: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Basisdatenpartition" PARTUUID = "?"

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

Wie Sie sehen, gibt es für jedes Feld 2 Beschreibungsfelder:

• Trennwand
• Dateisystem auf dieser Partition

In beiden Fällen ist die erste die vom Menschen lesbare Beschreibung und die zweite die Maschinenbeschreibung. Genau wie im Domain Name System (DNS), da die Maschinenbeschreibung - die UUID - eindeutig sein muss. Wir können also über nx 2 x 2 Datenfelder für Partitionen sprechen. Da die optischen Medien jedoch nicht partitioniert werden, gelten die Rohmedien als Partition. Das heißt, es gibt immer 2 x 2 = 4 Attribute. Versuchen wir, die UDF-Eigenschaften in das obige Beispiel einzufügen:

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

Ich habe stundenlang gesucht und viele Artikel gelesen, konnte dies aber nicht bestätigen. Das ist also nur eine Annahme. Für die LVID wird dies jedoch durch die Definition des Begriffs und durch einen Versuch sichergestellt. Linux und Windows, letztere mit WinCDemu, verwenden diese Eigenschaft als Bezeichnung für die Partition. Was für optische Medien das Medium selbst ist.

Eigentlich passt es ziemlich gut, wirft aber eine Frage auf. Es gibt eine zusätzliche UUID-Eigenschaft und ich neige dazu zu glauben, dass dies ein Implementierungsfehler ist. Weil ich einmal in diesem Netzwerk gelesen habe, dass dies später implementiert wurde, weil ppl. UDF-Medien konnten nicht über UUID gemountet werden. Es könnte also ein Missverständnis der angegebenen Eigenschaftsfelder gewesen sein. Ich weiß nicht, wo die aktuelle UUID abgelegt wird, aber blkid liest diese als UUID. Ich weiß nicht, ob dies ein Problem mit dem UDF-Treiber oder mit blkid ist. Vielleicht schreibt jemand eine Mail mit einem Hinweis an die entsprechende Person / Gruppe.