UDF'de birim tanıtıcısı, birim kümesi tanıtıcısı, mantıksal birim tanıtıcısı ve dosya kümesi tanıtıcısı arasındaki fark nedir?

görüyorum mkudffs dört farklı tanımlayıcı için seçenekleri vardır: mantıksal hacim ( --lvid ), ses ( --vid ), ses seviyesi --vsid ) ve dosya kümesi tanımlayıcısı ( --fsid ). Bununla birlikte, bunların ne anlama geldiğine rehberlik etmez.

Böylece UDF'nin özelliklerine gittim. ISO / IEC 13346 aka ile başlayan ECMA-167 , Şunu buldum:

10.1.4 Hacim Tanımlayıcı (BP 24)

Bu alan hacmin bir tanımını belirtir.

14.1.10 Mantıksal Hacim Tanımlayıcı (BP 112)

Bu alan, dosya setinin kaydedildiği mantıksal birimin bir tanımını belirtir.

14.1.12 Dosya Seti Tanımlayıcısı (BP 304)

Bu alan, bu Dosya Kümesi Tanımlayıcısı tarafından açıklanan dosya kümesinin bir tanımını belirtmelidir.

Bu faydalı oldu.

Bu yüzden denedim OSTA UDF Spec 1.02 , ben üretmeye çalışıyorum UDF sürümü olduğu gibi. Çok yardımcı olmadı (yine de beni "sabit veya önemsiz değerlere" karşı uyardı).

Denedim UDF 1.50 teknik özelliği bu da bana - §4.1'de - bu değerleri göstermeden önce, §4.1.2.1'de açıklanan algoritmaları kullanan bir işletim sistemine özgü dönüşümün uygulanması gerektiğini söyledi. Tabii ki, §4.1’den sonraki bölüm §4.2’dir, bu konuda size bol şans. Ayrıca, LogicalVolumeIdentifier "bir müzik kutusu içerisinde birden fazla medya bulunduğunda mantıksal hacim tanımlamasında son derece önemlidir. Ad genellikle kullanıcıya gösterilen addır."

Bu yüzden deniyorum UDF 2.01 teknik özellikleri ve şimdi biliyorum ki En azından şimdi 4 olduğunu fark ettiler. 2 .2.1 ki var olan fakat yardım etmeyen (karakter kümeleri gibi şeylerle ilgilenir).

Yani, söyleyebileceğim kadarıyla:

• Mantıksal Hacim Tanımlayıcı, kullanıcıya gösterilen şeydir (sadece müzik kutuları olabilir). Bu nedenle, örneğin disk başlığı gibi anlamlı bir şeye ayarlanmalıdır. Bunun Windows, Mac OS veya Nautilus'un görüntüleyeceği disk başlığı olduğunu varsayıyorum.
• Diğerleri yalnızca diskte yer açmak için var, ne için olduklarının gerçek bir açıklaması yok. Buna rağmen, onları ne sabit ne de önemsiz değerlere ayarlamalıyım. Muhtemelen, onları Shakespeare'den (yani önemsiz değil) rasgele (yani sabit değil) satırlarına ayarlamalıyım.

Veya daha iyisi: Diğer alanlar ne için?

Bunlar, yararlı olmayan karakter dizileridir. LVID .

Form mkudffs:

• --lvid Mantıksal birim tanımlayıcıyı belirtin. Verilen dizgiyi aşağıdaki alanlara ayarlar:
  • Mantıksal Hacim Tanımlayıcıdaki Mantıksal Hacim Tanımlayıcı (Bkz. Şekil 15, ECMA-167 )
  • Uygulama Kullanımında Mantıksal Hacim Tanımlayıcı. (Bkz. 2.2.7.2. UDF 2.01 )
  • Dosya Kümesi Tanımlayıcısındaki Mantıksal Birim Tanımlayıcısı. (Bkz. Şekil 9 ECMA-167 ) Dosya Kümesi Tanımlayıcısı. (Bkz. [ECMA-167] [5] deki Şekil 9).
    Pencerelerde disk etiketi olarak gösterilen Mantıksal Birim Tanımlayıcısı.
• --vid Birim tanımlayıcısını belirtin. Birincil Hacim Tanımlayıcısındaki Hacim Tanımlayıcı alanına hediye dizesini ayarlar. (Bkz. Şekil 6, ECMA-167 ). Maksimum uzunluk 31 bayt. Varsayılan değer "Linux UDF".
• --vsid Birim kümesi tanımlayıcısını belirtin. Verilen Birimi, Birim Birimi Açıklayıcısı'ndaki birim kümesi tanımlayıcı alanına ayarlar. (Bkz. Şekil 6, ECMA-167 ). Maksimum uzunluk 127 bayt. Varsayılan değer "Linux UDF".
  Birim Küme Tanımlayıcısı, ImgBurn, MagicISO gibi bazı Disk geliştirme programları tarafından düzenlenebilir. Birimin üyesi olduğu birim kümesinin bir tanımını belirtir.
• --fsid Dosya kümesi tanımlayıcısını belirtin. Dosya Kümesi Tanımlayıcısı'ndaki Dosya Kümesi Tanımlayıcı alanını ayarlar. (Bkz. Şekil 9 ECMA-167 ). Maksimum uzunluk 31 bayt. Varsayılan değer "Linux UDF".

Bence bunlar tamamen size kalmış; Alanların kurumsal süreçleri desteklemek için orada olduğunu söyleyebilirim. Kolayca akla gelen bir kullanım, "FOO’nun aylık tam yedeği", 2015-12 "gibi şeyler için birim kümesi tanımlayıcısının kullanılması ve birim tanıtıcısının" disk 1/42 "gibi olması olabilir. Ya da belki fiziksel bir tanımlayıcınız olur, örn. disk üzerine basılmış bir barkod ve birim tanımlayıcısı bunu tutabilir (diski sürücüde okuyarak veya barkod okuyucuyu işaret ederek tanımlayabilirsiniz).

Dosya kümesi tanımlayıcısının, dosya sistemine bir tür mantıksal birim ("set") oluşturan bir grup dosya koyarken yararlı olabileceğini hayal ediyorum, ancak sezgisel olarak bir "birim" oluşturmuyorlar; örneğin, "Mariah Carey .gifs 1994-1998" veya "Bob'un lise makaleleri".

Mantıklı konuşursak, bu alanların tümü, standardı geliştiren ve / veya değiştiren bir komite üyesinin (veya üyelerinin) ihtiyaç duyduğu verileri içerdiği için var. Sırf birinin diskte yer kaybı olduğunu düşündüğü için, standardın üzerinde anlaşıldığı zaman, konuyla ilgili bir veya daha fazla görüş olmadığı anlamına gelmez. Aslında, bazı üyeler veya komite üyeleri, onları bir amaç için ya da başka bir standarda girebildikleri kadar faydalı buluyorlardı. Bir standartta açıkça tanımlanmayan herhangi bir şeyin yorumlamaya açık olduğunu ve bu nedenle, ne tür bir amaç için kullanılabileceğini veya standart tarafından açıkça tanımlanana kadar güvenle göz ardı edilebileceğini söylüyorum. Bir yazılım geliştirme perspektifinden 'mkudffs' Bu alanları ne için kullanmanız gerektiğini tanımlamanıza gerek yoktur, yalnızca uygun gördüğünüz şekilde kullanmanıza (veya perspektife bağlı olarak yanlış kullanmanıza) izin vermeniz için bir mekanizma sağlayın, böylece standarda uyun .

Bence bu değerler, medya yayınlarını genelleştirmeye çalıştıkları diğer özelliklere yöneliyorlar. Benim örneğimde Linux'a başvuracağım ama bu, Windows için geçerli olmayacağı anlamına gelmiyor. Bu özellikler sadece orada saklı.

Linux'ta aşağıdaki cmd'yi çalıştırın ve çıktıya bakın: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = "ntfs" PARTLABEL = "Temel veri bölümü" PARTUUID = "?"

/ dev / y: LABEL = "Linux" UUID = "?" TYPE = "ext4" PARTLABEL = "depolama alanı" PARTUUID = "?"

Gördüğünüz gibi, her biri için 2 açıklama alanı var:

• bölme
• Bu bölümdeki dosya sistemi

Her iki durumda da, birincisi insan tarafından okunabilen tanımdır ve ikincisi de makine tanımlamasıdır. Tıpkı Alan Adı Sisteminde (DNS) olduğu gibi, makine tanımının - UUID - benzersiz olması gerektiğinden. Böylece bölümler için n x 2 x 2 veri alanlarından bahsedebiliriz. Ancak, optik ortam bölümlenemediğinden, ham ortam bölümün kendisi olarak sayılır. Bu da her zaman 2 x 2 = 4 özellik olduğu anlamına gelir. UDF özelliklerini yukarıdaki örneğe sığdırmaya çalışalım:

/ dev / x: LABEL = "LVID" UUID = "VID" TİP = "UDF" PARTLABEL = "VSID" PARTUUID = "FSID"

Saatlerce aradım ve birçok makale okudum, ancak bunu doğrulayamadım. Yani bu sadece bir varsayım. Ancak LVID için, terimin tanımı ve deneme ile güvence altına alınmıştır. WinCDemu'ya sahip Linux ve Windows, bu özelliği bölüm etiketi olarak kullanır. Bu, optik ortam için ortamın kendisidir.

Aslında oldukça düzgün uyuyor, ancak bir soruyu gündeme getiriyor. Ek bir UUID özelliği var ve bunun bir tür uygulama hatası olduğuna inanıyorum. Çünkü bir zamanlar bu ağda okudum, bunun daha sonra uygulandığını, çünkü ppl. UDF ortamını UUID ile bağlayamadı. Dolayısıyla, verilen mülkiyet alanlarının yanlış anlaşılması olabilir. Şu anki UUID'nin nereye konulduğunu bilmiyorum, ancak blkid bunu UUID olarak okuyor. Bunun bir UDF sürücüsü mü yoksa blkid sorunu mu olduğunu bilmiyorum. Belki birileri ilgili kişiye / gruba ipucu ile bir posta yazar.