Och, ale to jest pytanie o zawartość pliku w tarpliku. W rzeczywistości w niektórych przypadkach nie jest to takie trudne. Chodzi o to, że tarplik jest po prostu zablokowanym plikiem strumieniowym - każdy plik w archiwum znajduje się po pliku przed nim, a każdy plik otrzymuje nagłówek metadanych oparty na określonym formacie .
Opierając się na tym formacie, napisałem kiedyś shitar- który był kilkoma wierszami ddskryptów powłoki i które mogły w targórę przesyłać strumień urządzeń blokowych. Na tej samej podstawie napisałem kilka wierszy kodu :
tar --no-recursion -c ./ |
{ printf \\0; tr -s \\0; } |
cut -d '' -f-2,13 |
tr '\0\n' '\n\t'
... do wybierania tarpliku w locie i wykonywania wbudowanych przekształceń w składowych plikach tekstowych. Tam cutpola wskazują na pola 1,2,13 linii danych ograniczonych NUL . Takie rzeczy są łatwe, gdy tarplik zawiera tylko pliki tekstowe, ponieważ tarograniczniki rekordów (co może się zdarzyć raz na 512 bajtów) można po prostu zmniejszyć do jednego NUL na i usunąć - bez konieczności liczenia wystąpień tak jak Ty.
tarFormat nagłówka wygląda następująco:
field offset len
name 0 100
mode 100 8
uid 108 8
gid 116 8
size 124 12
mtime 136 12
chksum 148 8
typeflag 156 1
linkname 157 100
magic 257 6
version 263 2
uname 265 32
gname 297 32
devmajor 329 8
devminor 337 8
prefix 345 155
Zrozum, że istnieje stosunkowo duże nachylenie między względną łatwością obsługi prostych taroperacji a znacznie bardziej skomplikowanymi aspektami formatu archiwum. Podczas gdy proste rzeczy - takie jak spakowanie niewielkiej grupy jednorodnie wpisanych plików lub nawet podzielenie archiwum zawierającego tylko elementy, których typy można przewidzieć - można łatwo wykonać za pomocą kilku potoków powłoki, niezawodna obsługa dowolnych elementów archiwum nie jest drobnostką.
Jest to szczególnie trudne, gdy członkowie ci mogą zawierać dowolne dane binarne - co z pewnością uniemożliwiałoby jakiekolwiek niezawodne zastosowanie tr -s- i trudność ta się komplikuje tylko wtedy, gdy używane są pliki różnych typów niż zwykłe i / lub zestawy znaków inne niż Twój i / lub oryginalne archiwum zostało utworzone przez implementację z specyfikacjami aplikacji formatu, których nie jesteś przygotowany do obsługi. Dotyczy to tylko podstawowych, znormalizowanych aspektów tartypu archiwum - dodaj rozszerzone nagłówki i rozszerzenia formatu oraz rzadkie pliki i kompresję i ... no cóż, powodzenia z nimi.
Wracając jednak do podstaw, standardowy rozmiar rekordu dla tararchiwum to 20 bloków - lub 10240 bajtów. Biorąc pod uwagę, że archiwum jest zablokowane na standardowym rozmiarze rekordu i zawiera tylko standardowe typy plików i standardowe ustarnagłówki, należy przechodzić od nagłówka członka do nagłówka członka, wykonując odczyty zgodnie z sizepolem nagłówka, dopóki nie znajdzie się elementu pasującego do tego dla którego szukasz. Tam wczytaj sizebajty z przesunięcia rozpoczynającego się na końcu nagłówka elementu docelowego. I to twój plik.
Jednak przeskakiwanie nagłówków nie jest strasznie łatwe. Różne typy będą albo nie będą miały dołączonych faktycznych bloków danych, które odpowiadają size. Na przykład katalogi i łącza nie będą zawierały takiego bloku danych, tylko opis nagłówka, więc musisz być przygotowany do zweryfikowania typu pliku bieżącego nagłówka przed upewnieniem się, czy powinieneś zastosować jego sizepole do formuły pominięcia, czy nie.
Ponadto czynniki związane z rozmiarem rekordu - w zależności od tego, czy rozmiary członków archiwum są dobrze zsynchronizowane ze standardowym rekordem 10240 - rozmiar może być dołączony do każdego dodatkowego bloku 0 lub nie. A rekord może zostać uznana -size w momencie tworzenia archiwum - a więc nie może być nawet 20 bloków wcale, chociaż, według specyfikacji, to zawsze musi być zablokowane w jednostkach 512-bajtowych:
- ustar
tarFormat wymiany; patrz sekcja OPIS ROZSZERZONY . Domyślny rozmiar bloków dla tego formatu dla specjalnych plików archiwów to 10240 . Implementacje obsługują wszystkie wartości wielkości bloku mniejsze lub równe 32256, które są wielokrotnościami 512 .
Więc jeśli pracujesz z tarplikiem, który może zawierać pliki, które mogą zawierać dowolne dane binarne, musisz przejść przez plik algorytmicznie i zgodnie z typem pliku. Specyfikacja mówi:
sizePole jest rozmiar pliku w oktetów.
- Jeżeli
typeflagpole jest ustawione tak, aby określać plik typu 1 ( łącze ) lub 2 ( łącze symboliczne ) , sizepole należy podać jako zero.
- Jeżeli
typeflagpole jest ustawione tak, aby określać plik typu 5 ( katalog ) , sizepole należy interpretować zgodnie z opisem pod definicją tego typu rekordu.
- Żadne logiczne rekordy danych nie są przechowywane dla typów 1 , 2 lub 5 .
- Jeśli
typeflagpole ma wartość 3 ( znak specjalny plik) , 4 ( blokowy plik specjalny ) lub 6 ( FIFO ) , znaczenie tego sizepola nie jest określone w tym tomie POSIX.1-2008 i żadne rekordy logiczne danych nie będą przechowywane na nośniku.
- Dodatkowo, dla typu 6 ,
sizepole elektromagnetyczne powinny być ignorowane podczas czytania.
- Jeśli w
typeflagpolu ustawiono inną wartość, liczba rekordów logicznych zapisanych po nagłówku wynosi , ignorując ułamek wynikający z podziału.( (size+ 511 ) / 512 )
... i oczywiście biorąc pod uwagę także indywidualny rozmiar każdego nagłówka - co stanowi dodatkowy blok na element. Możesz więc przejść do odczytu przez odczyt z nagłówka do nagłówka, aż dojdziesz do jednego pasującego do szukanego nagłówka, w którym to momencie musisz sprawdzić, czy bieżący rekord opisuje jedynie link do pliku lub do rzeczywistego pliku . Jest to szczególnie istotne, ponieważ gdy ten sam plik jest dodawany do archiwum wiele razy, wiele tars będzie zawierać tylko nagłówki linków, ponieważ rzeczywiste dane pliku można już znaleźć gdzie indziej w archiwum.
Po sprawdzeniu, że musisz zastosować swoje obliczenia do chksumpola i zweryfikować, że plik, który Twoim zdaniem masz, jest w rzeczywistości plikiem, który chcesz. tar„s chksumjest dość prosta chociaż-:
- cksum
chksumPole powinno być ISO / IEC 646: 1991 norma IRV reprezentację ósemkowej wartości prostej sumy wszystkich oktetów w nagłówku rekordu logicznego. Każdy oktet w nagłówku należy traktować jako wartość bez znaku. Wartości te należy dodać do liczby całkowitej bez znaku, zainicjowanej na zero, której dokładność nie jest mniejsza niż 17 bitów. Przy obliczaniu sumy kontrolnej chksumpole jest traktowane tak, jakby to były wszystkie znaki <spacja> .
Oczywiście tak naprawdę nie musiałbyś tego robić, ponieważ tarmożesz już to zrobić - tak właśnie działa - dlatego prawdopodobnie powinieneś po prostu użyć go do przeszukania archiwum i wyodrębnienia pliku za Ciebie. Czyniąc to, nie zrobi nic inaczej niż zrobiłbyś, gdybyś wiedział, o co ci chodzi, poza tym, że prawdopodobnie zrobi to lepiej i szybciej, ponieważ taka jest jego praca. A zresztą dlaczego miałbyś?