W UDF, jaka jest różnica między identyfikatorem woluminu, identyfikatorem zestawu woluminów, logicznym identyfikatorem woluminu i identyfikatorem zestawu plików?

Widzę, że mkudffsma opcje dla czterech różnych identyfikatorów: wolumin logiczny ( --lvid), wolumin ( --vid), zestaw woluminów ( --vsid) i identyfikator zestawu plików ( --fsid). Nie daje jednak wskazówek, co to znaczy.

Więc poszedłem do specyfikacji UDF. Począwszy od ISO / IEC 13346 aka ECMA-167 , stwierdzam, że:

10.1.4 Identyfikator objętości (BP 24)

To pole określa identyfikator wolumenu.

14.1.10 Identyfikator woluminu logicznego (BP 112)

To pole określa identyfikację woluminu logicznego, na którym zestaw plików jest rejestrowany.

14.1.12 Identyfikator zestawu plików (BP 304)

To pole określa identyfikację zestawu plików opisanego przez ten deskryptor zestawu plików.

To było przydatne.

Wypróbowałem OSTA UDF Spec 1.02 , ponieważ to jest wersja UDF, którą próbuję wygenerować. To niewiele pomogło (choć ostrzegało mnie przed „ustalonymi lub trywialnymi wartościami”).

Wypróbowałem specyfikację UDF 1.50, która dodatkowo mówi mi - w §4.1 - że przed wyświetleniem tych wartości należy zastosować transformację specyficzną dla systemu operacyjnego przy użyciu algorytmów opisanych w §4.1.2.1. Oczywiście następna sekcja po §4.1 to §4.2, więc powodzenia. Ponadto LogicalVolumeIdentifier jest „niezwykle ważny w logicznej identyfikacji woluminu, gdy w szafie grającej znajduje się wiele mediów. Nazwa jest zwykle wyświetlana użytkownikowi”.

Więc staram się 2,01 specyfikację UDF , a teraz wiem, że teraz przynajmniej oni sobie sprawę, że to 4. 2 .2.1, który nie istnieje, ale nie pomaga (nie dotyczy rzeczy jak zestawy znaków).

Tak więc, o ile mogę powiedzieć:

• Identyfikator woluminu logicznego jest wyświetlany użytkownikowi (być może tylko szafami grającymi). Więc powinno być ustawione na coś znaczącego, np. Tytuł płyty. Zakładam, że jest to tytuł dysku, który wyświetlałby Windows, Mac OS lub Nautilus.
• Inne istnieją tylko po to, by marnować miejsce na dysku, nie mając faktycznego opisu tego, do czego służą. Mimo to powinienem ustawić je na wartości, które nie są ani stałe, ani trywialne. Być może powinienem po prostu ustawić je na losowe (tj. Nie naprawione) linie Szekspira (tj. Nie trywialne).

Albo jeszcze lepiej: do czego służą inne pola?

Są to niepotrzebne ciągi, z wyjątkiem LVID .

Formularz mkudffs:

• --lvid Podaj identyfikator woluminu logicznego. Ustawia podany ciąg do następujących pól:
  • Identyfikator woluminu logicznego w deskryptorze woluminu logicznego (patrz rysunek 15 w ECMA-167 )
  • Identyfikator woluminu logicznego w implementacji Zastosowanie. (Patrz 2.2.7.2 w UDF 2.01 )
  • Identyfikator woluminu logicznego w deskryptorze zestawu plików. (Patrz rysunek 9 w ECMA-167 ) Deskryptor zestawu plików. (Patrz rysunek 9 w [ECMA-167] [5]).
    Identyfikator woluminu logicznego wyświetlany w systemie Windows jako etykieta dysku.
• --vid Podaj identyfikator woluminu. Ustawia podany ciąg w polu Identyfikator woluminu w głównym deskryptorze woluminu. (Patrz rysunek 6 w ECMA-167 ). Maksymalna długość 31 bajtów. Wartość domyślna „Linux UDF”.
• --vsid Podaj identyfikator zestawu woluminów. Ustawia podany ciąg do pola identyfikatora zestawu woluminów w Primary Volume Desriptor. (Patrz rysunek 6 w ECMA-167 ). Maksymalna długość 127 bajtów. Wartość domyślna „Linux UDF”.
  Identyfikator zestawu woluminów może być edytowany przez niektóre programy do tworzenia dysków, takie jak ImgBurn, MagicISO. Określa identyfikację zestawu woluminów, którego członkiem jest wolumin.
• --fsid Podaj identyfikator zestawu plików. Ustawia pole Identyfikator zestawu plików w deskryptorze zestawu plików. (Patrz rysunek 9 w ECMA-167 ). Maksymalna długość 31 bajtów. Wartość domyślna „Linux UDF”.

Myślę, że to zależy od ciebie; Powiedziałbym, że są tam pola do wspierania procesów korporacyjnych. Jednym z pomysłów, które przychodzi mi na myśl, jest użycie identyfikatora zestawu woluminów do takich rzeczy, jak „miesięczna pełna kopia zapasowa FOO, 2015-12”, a identyfikatorem woluminu może być coś w rodzaju „dysku 1 z 42”. A może faktycznie będziesz mieć fizyczny identyfikator, np. Kod kreskowy, wydrukowany na dysku, a identyfikator woluminu może to pomieścić (dzięki czemu możesz zidentyfikować dysk albo przez odczytanie go z napędu, albo poprzez skierowanie na niego czytnika kodów kreskowych ).

Wyobrażam sobie, że identyfikator zestawu plików może być przydatny, gdy umieszczasz w systemie plików kilka plików, które tworzą jakąś jednostkę logiczną („zestaw”), ale nie tworzą intuicyjnie „woluminu”; na przykład „Mariah Carey .gifs 1994-1998” lub „eseje licealne Boba”.

Logicznie rzecz biorąc, wszystkie te pola zawierają dane, których potrzebował pewien członek (lub członkowie) komitetu, który opracował i / lub zmodyfikował standard. To, że ktoś myśli, że to marnowanie miejsca na dysku, nie oznacza, że ​​nie było jednej lub więcej opinii w tej sprawie, kiedy standard został uzgodniony. W rzeczywistości niektórzy członkowie lub członkowie komitetu uważali ich za wystarczająco użytecznych do takiego czy innego celu, który wprowadzili do normy. Mówię, że wszystko, co nie jest wyraźnie zdefiniowane w standardzie, jest otwarte na interpretację i dlatego może być użyte do dowolnego celu, który chcesz, lub bezpiecznie zignorowane, dopóki nie zostanie to wyraźnie określone przez standard. Z punktu widzenia tworzenia oprogramowania „mkudffs” nie musi określać, do czego należy używać tych pól,

Myślę, że te wartości dotyczą innych specyfikacji, które same próbują uogólnić media mngt. W moim przykładzie będę odwoływał się do Linuksa, ale to nie znaczy, że nie będzie miało zastosowania do systemu Windows. Te specyfikacje. są tam po prostu ukryte.

Uruchom następujący cmd w systemie Linux i spójrz na wynik: blkid

/ dev / x: LABEL = "Windows" UUID = "?" TYPE = „ntfs” PARTLABEL = „Podstawowa partycja danych” PARTUUID = „?”

/ dev / y: LABEL = "Linux" UUID = "?" TYPE = „ext4” PARTLABEL = „pamięć” PARTUUID = „?”

Jak widać, istnieją 2 pola opisu dla każdego:

• Przegroda
• System plików na tej partycji

W obu przypadkach pierwszy to opis czytelny dla człowieka, a drugi opis maszyny. Podobnie jak w systemie nazw domen (DNS), ponieważ opis komputera - UUID - musi być unikalny. Możemy więc mówić o polach danych nx 2 x 2 dla partycji. Ponieważ jednak nośnik optyczny nie zostanie podzielony na partycje, nieprzetworzone nośniki liczą się jako sama partycja. Co oznacza, że ​​zawsze są 2 x 2 = 4 atrybuty. Spróbujmy dopasować właściwości UDF do powyższego przykładu:

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

Szukałem godzin i czytałem wiele artykułów, ale nie mogłem tego zweryfikować. To tylko założenie. Ale w przypadku LVID jest to zapewnione z definicji tego terminu i na podstawie próby. Linux i Windows, ten ostatni z WinCDemu, używają tej właściwości jako etykiety partycji. Dla mediów optycznych jest to samo medium.

Właściwie pasuje całkiem nieźle, ale rodzi się jedno pytanie. Istnieje dodatkowa właściwość UUID i mam skłonność wierzyć, że jest to pewnego rodzaju błąd implementacji. Ponieważ kiedyś czytałem w tej sieci, że zostało to zaimplementowane później, ponieważ ppl. nie mogliśmy zamontować nośnika UDF przez UUID. Być może było to nieporozumienie z danymi polami właściwości. Nie wiem, gdzie jest umieszczony bieżący UUID, ale blkid czyta ten jako UUID. Nie wiem, czy jest to sterownik UDF, czy problem z blkid. Może ktoś pisze wiadomość z podpowiedź do odpowiedniej osoby / grupy.