Ah, pero esta es una pregunta sobre el contenido de un archivo dentro de un tararchivo. Y en realidad, en algunos casos esto no es tan difícil. La cuestión es que un tararchivo es solo un archivo de flujo bloqueado: cada archivo dentro del archivo se encuentra después del anterior, y cada archivo obtiene un encabezado de metadatos basado en un formato específico .
Sobre la base de ese formato, una vez escribí shitar, que consistía en unas pocas líneas ddy scripts de shell que podían targenerar una corriente de dispositivos de bloque sobre la marcha. Basado en lo mismo, más recientemente escribí estas pocas líneas de código :
tar --no-recursion -c ./ |
{ printf \\0; tr -s \\0; } |
cut -d '' -f-2,13 |
tr '\0\n' '\n\t'
... para separar un tararchivo sobre la marcha y realizar transformaciones en línea en sus archivos de texto componente. Allí los cutcampos apuntan a los campos 1,2,13 de una línea de entrada delimitada por NUL . Tales cosas son fáciles cuando el tararchivo contiene solo archivos de texto porque tarlos delimitadores de registro (como puede ocurrir una vez cada 512 bytes) pueden reducirse a un solo NUL por unidad y eliminarse, sin requerir que cuente las ocurrencias como lo hace.
tarEl formato del encabezado se ve así:
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
Comprenda que existe una fuerte pendiente entre la relativa facilidad de manejar taroperaciones simples con los aspectos mucho más complicados del formato de archivo. Si bien las cosas simples, como agrupar un pequeño grupo de archivos tipeados de manera homogénea o incluso dividir un archivo que contiene solo miembros cuyos tipos se pueden predecir, se pueden hacer fácilmente con unas pocas tuberías, manejar de manera confiable miembros de archivos arbitrarios no es un asunto trivial.
Es especialmente difícil cuando esos miembros pueden contener datos binarios arbitrarios, lo que ciertamente excluiría cualquier aplicación confiable de tr -s, y esta dificultad solo se agrava cuando se usan archivos de varios tipos que no sean regulares y / o charsets que no sean el nativo y / o el el archivo original fue creado por una implementación con idiosincrasias de aplicación de formato que no está preparado para manejar. Y esto solo toca los aspectos básicos y estandarizados del tartipo de archivo: agregue encabezados extendidos y extensiones de formato y archivos dispersos y compresión y ... bueno, buena suerte con ellos.
Sin embargo, volviendo a lo básico, el tamaño de registro estándar para un tararchivo es de 20 bloques, o 10240 bytes. Sin ustarembargo, dado un archivo bloqueado en el tamaño de registro estándar y que contiene solo tipos de archivo estándar y encabezados estándar , debe saltar del encabezado de miembro al encabezado de miembro haciendo lecturas de acuerdo con el sizecampo de encabezado hasta que encuentre un miembro que coincida con el de que buscas Una vez allí, lea en sizebytes desde el desplazamiento que comienza en la cola del encabezado de miembro de su objetivo. Y ese es tu archivo.
Sin embargo, saltear los encabezados no es terriblemente fácil. Los diferentes tipos tendrán o no bloques de datos reales anexados que correspondan size. Por ejemplo, los directorios y enlaces no contendrán dicho bloque de datos, solo una descripción del encabezado, por lo que debe estar preparado para verificar el tipo de archivo del encabezado actual antes de determinar exactamente si debe aplicar su sizecampo a su fórmula de omisión o no.
Además, los factores de tamaño de registro , dependiendo de si los tamaños de los miembros del archivo se sincronizan bien con el tamaño de registro estándar 10240, puede haber o no un bloque 0 adicional agregado a cada uno. Y el tamaño del registro se puede declarar en el momento de la creación del archivo, por lo que es posible que ni siquiera tenga 20 bloques, aunque, por especificación, siempre debe estar bloqueado en unidades de 512 bytes:
- ustar
- El
tarformato de intercambio; vea la sección DESCRIPCIÓN EXTENDIDA . El tamaño de bloque predeterminado para este formato para archivos de caracteres especiales será 10240 . Las implementaciones admitirán todos los valores de tamaño de bloque menores o iguales a 32256 que son múltiplos de 512 .
Entonces, si estaba trabajando con un tararchivo que podría contener archivos que podrían contener datos binarios arbitrarios, tendría que omitir el archivo algorítmicamente y de acuerdo con el tipo de archivo. La especificación dice:
- El
sizecampo es el tamaño del archivo en octetos.
- Si el
typeflagcampo está configurado para especificar que un archivo sea de tipo 1 (un enlace ) o 2 (un enlace simbólico ) , el sizecampo se especificará como cero.
- Si el
typeflagcampo está configurado para especificar un archivo de tipo 5 ( directorio ) , el sizecampo se interpretará como se describe en la definición de ese tipo de registro.
- No se almacenan registros lógicos de datos para los tipos 1 , 2 o 5 .
- Si el
typeflagcampo se establece en 3 ( archivo especial de caracteres ) , 4 ( archivo especial de bloque ) o 6 ( FIFO ) , sizeeste volumen de POSIX.1-2008 no especifica el significado del campo y no se registrarán registros lógicos de datos almacenado en el medio.
- Además, para el tipo 6 , el
sizecampo se ignorará al leer.
- Si el
typeflagcampo se establece en cualquier otro valor, el número de registros lógicos escritos después del encabezado será , ignorando cualquier fracción en el resultado de la división.( (size+ 511 ) / 512 )
... y, por supuesto, teniendo en cuenta también el tamaño individual de cada encabezado, que es un bloque adicional por miembro. Por lo tanto, puede pasar de una lectura a otra de encabezado a encabezado hasta que encuentre uno que coincida con el encabezado que busca, en ese momento deberá verificar si el registro actual simplemente describe un enlace a su archivo o al archivo real . Esto es especialmente relevante porque cuando el mismo archivo se agrega a un archivo varias veces, muchos tars solo incluirán encabezados de enlace porque los datos del archivo real ya se pueden encontrar en otras partes del archivo.
Después de verificar que necesitarás aplicar tus cálculos al chksumcampo y verificar que el archivo que crees que tienes es en realidad el archivo que deseas después de todo. tarSin chksumembargo, es bastante simple:
- cksum
- El
chksumcampo será la representación IRV estándar ISO / IEC 646: 1991 del valor octal de la suma simple de todos los octetos en el registro lógico del encabezado. Cada octeto en el encabezado se tratará como un valor sin signo. Estos valores se agregarán a un entero sin signo, inicializado a cero, cuya precisión no sea inferior a 17 bits. Al calcular la suma de verificación, el chksumcampo se trata como si fuera todo <space> caracteres.
Por supuesto, en realidad no tendría que hacer nada de eso, porque tarya puede hacerlo, eso es lo que hace, por lo que probablemente debería usarlo para buscar en el archivo y extraer el archivo por usted. Al hacerlo, no hará nada muy diferente de lo que haría si supiera de qué se trata, excepto que probablemente lo hará mejor y más rápido porque ese es su trabajo. Y de todos modos, ¿por qué deberías?