Oh, ma questa è una domanda sul contenuto di un file all'interno di un tarfile. E in realtà, in alcuni casi non è così difficile. Il fatto è che un tarfile è solo un file di flusso bloccato: ogni file all'interno dell'archivio si trova dopo quello precedente e ogni file ottiene un'intestazione di metadati basata su un formato specificato .
Sulla base di quel formato, una volta ho scritto shitar- che era un paio di righe dde script di shell che potevano taral volo un flusso di dispositivi a blocchi. Basato sullo stesso, più recentemente ho scritto queste poche righe di codice :
tar --no-recursion -c ./ |
{ printf \\0; tr -s \\0; } |
cut -d '' -f-2,13 |
tr '\0\n' '\n\t'
... per separare un tarfile al volo ed eseguire trasformazioni in linea sui suoi file di testo componenti. Lì i cutcampi puntano ai campi 1,2,13 di una riga di input delimitata NUL . Queste cose sono facili quando il tarfile contiene solo file di testo perché tari delimitatori di record (come potrebbe accadere una volta ogni 512 byte) possono essere semplicemente ridotti a un singolo NUL per e rimossi - senza che sia necessario contare le occorrenze mentre lo si fa.
tarIl formato dell'intestazione è simile al seguente:
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
Comprendi che esiste una forte pendenza tra la relativa facilità di gestione delle operazioni semplici tarcon gli aspetti molto più complicati del formato dell'archivio. Mentre cose semplici - come mettere insieme un piccolo gruppo di file tipizzati in modo omogeneo o persino dividere un archivio contenente solo membri di cui si possono prevedere i tipi - possono essere facilmente fatti con poche pipe shell, gestire in modo affidabile membri arbitrari dell'archivio non è una cosa da poco.
È particolarmente difficile quando quei membri potrebbero contenere dati binari arbitrari - il che certamente impedirebbe qualsiasi applicazione affidabile di tr -s- e questa difficoltà si aggrava solo quando vengono utilizzati file di vario tipo diversi da quelli normali e / o diversi da quello nativo e / o l'archivio originale è stato creato da un'implementazione con idiosincrasie di applicazioni in formato che non si è pronti a gestire. E questo tocca solo gli aspetti standardizzati di base del tartipo di archivio: aggiungi intestazioni estese ed estensioni di formato, file sparsi e compressione e ... beh, buona fortuna con quelli.
Torna alle origini, tuttavia, la dimensione standard del record per un tararchivio è di 20 blocchi - o 10240 byte. Dato un archivio bloccato sulla dimensione del record standard e contenente solo i tipi di file standard e le ustarintestazioni standard , tuttavia, è necessario saltare da intestazione membro a intestazione membro eseguendo le letture in base al sizecampo dell'intestazione fino a trovare un membro corrispondente a quello per che cerchi. Una volta lì, leggi i sizebyte dall'offset a partire dalla coda dell'intestazione del membro di destinazione. E questo è il tuo file.
Saltare le intestazioni non è terribilmente facile, però. Diversi tipi avranno o non avranno allegati blocchi di dati reali corrispondenti size. Ad esempio, le directory e i collegamenti non contengono tali blocchi di dati, solo una descrizione dell'intestazione e quindi è necessario essere pronti a verificare il tipo di file dell'intestazione corrente prima di accertare esattamente se è necessario applicare il sizecampo alla formula di salto o meno.
Inoltre, i fattori di dimensione del record - a seconda che le dimensioni dei membri dell'archivio si sincronizzino o meno con la dimensione del record standard 10240, potrebbero essere aggiunti o meno un blocco 0 aggiuntivo a ciascuno. E il record- size può essere dichiarato al momento della creazione dell'archivio - e quindi potrebbe non essere nemmeno di 20 blocchi, anche se, per specifica, deve sempre essere bloccato su unità da 512 byte:
- USTAR
- Il
tarformato di interscambio; vedere la sezione DESCRIZIONE ESTESA . La dimensione di blocco predefinita per questo formato per i file di archivio speciali dei caratteri è 10240 . Le implementazioni devono supportare tutti i valori di blocchi di dimensioni inferiori o uguali a 32256 che sono multipli di 512 .
Quindi, se lavorassi con un tarfile che potrebbe contenere file che potrebbero contenere dati binari arbitrari, dovrai saltare il file in modo algoritmico e in base al tipo di file. Le specifiche dicono:
- Il
sizecampo è la dimensione del file in ottetti.
- Se il
typeflagcampo è impostato per specificare un file di tipo 1 (un collegamento ) o 2 (un collegamento simbolico ) , il sizecampo deve essere specificato come zero.
- Se il
typeflagcampo è impostato per specificare un file di tipo 5 ( directory ) , il sizecampo deve essere interpretato come descritto nella definizione di quel tipo di record.
- Nessun record logico di dati viene archiviato per i tipi 1 , 2 o 5 .
- Se il
typeflagcampo è impostato su 3 ( file speciale di caratteri ) , 4 ( blocco file speciale ) o 6 ( FIFO ) , il significato del sizecampo non è specificato da questo volume di POSIX.1-2008 e nessun record logico di dati deve essere memorizzato sul supporto.
- Inoltre, per il tipo 6 , il
sizecampo deve essere ignorato durante la lettura.
- Se il
typeflagcampo è impostato su qualsiasi altro valore, il numero di record logici scritti dopo l'intestazione deve essere , ignorando qualsiasi frazione nel risultato della divisione.( (size+ 511 ) / 512 )
... e, ovviamente, considerando anche le dimensioni individuali di ciascuna intestazione - che è un blocco aggiuntivo per membro. Quindi potresti saltare attraverso la lettura dall'intestazione all'intestazione fino a quando non atterri su una corrispondente all'intestazione per la quale stai cercando, a quel punto dovresti quindi controllare se il record corrente descrive semplicemente un collegamento al tuo file o al file effettivo . Ciò è particolarmente rilevante perché quando lo stesso file viene aggiunto a un archivio più volte molte tars includeranno solo le intestazioni dei collegamenti poiché i dati del file effettivo possono già essere trovati altrove all'interno dell'archivio.
Avendo verificato che dovrai applicare i tuoi calcoli al chksumcampo e verificare che il file che pensi di avere sia effettivamente il file che desideri dopo tutto. tar's chksumè abbastanza semplice anche se-:
- cksum
- Il
chksumcampo deve essere la rappresentazione IRV standard ISO / IEC 646: 1991 del valore ottale della somma semplice di tutti gli ottetti nel record logico dell'intestazione. Ogni ottetto nell'intestazione deve essere trattato come un valore senza segno. Questi valori devono essere aggiunti a un numero intero senza segno, inizializzato su zero, la cui precisione non è inferiore a 17 bit. Quando si calcola il checksum, il chksumcampo viene trattato come se fosse composto da tutti i caratteri <spazio> .
Certo, non dovresti davvero farlo, perché tarpuoi già farlo - ecco cosa fa - e quindi probabilmente dovresti semplicemente usarlo per cercare nell'archivio ed estrarre il file per te. In tal modo non farà nulla di molto diverso da quello che faresti se sapessi di cosa ti occupavi, tranne per il fatto che probabilmente lo farà meglio e più velocemente perché è il suo lavoro. E comunque, perché dovresti?