โอ้ แต่นี่เป็นคำถามเกี่ยวกับเนื้อหาของไฟล์ภายในtarไฟล์ และในบางกรณีมันไม่ยาก สิ่งที่เป็นtarไฟล์เป็นเพียงบล็อกไฟล์สตรีม - แต่ละไฟล์ภายในเก็บที่พบหลังจากที่หนึ่งก่อนที่มันและแต่ละไฟล์ได้รับข้อมูลเมตาหัวขึ้นอยู่กับรูปแบบที่กำหนด
ตามรูปแบบที่ฉันเคยเขียนshitar- ซึ่งเป็นไม่กี่บรรทัดddและเชลล์สคริปต์ซึ่งสามารถtarเพิ่มกระแสของอุปกรณ์บล็อกได้ทันที เมื่อเร็ว ๆ นี้ฉันได้เขียนโค้ดสองสามบรรทัดนี้ขึ้น :
tar --no-recursion -c ./ |
{ printf \\0; tr -s \\0; } |
cut -d '' -f-2,13 |
tr '\0\n' '\n\t'
... สำหรับการแยกtarไฟล์อย่างรวดเร็วและทำการแปลงแบบอินไลน์ในไฟล์ข้อความส่วนประกอบ มีcutฟิลด์ที่ชี้ไปที่ฟิลด์1,2,13ของบรรทัดอินพุตNUL ที่คั่นด้วย สิ่งต่าง ๆ นั้นง่ายเมื่อtarไฟล์นั้นมีเพียงไฟล์ข้อความเพราะtarตัวคั่นเรคคอร์ด(ซึ่งอาจเกิดขึ้นหนึ่งครั้งต่อ 512 ไบต์)สามารถบีบลงเป็น NUL เดียวต่อหนึ่งและถูกตัดออกโดยไม่ต้องให้คุณนับเหตุการณ์เช่นเดียวกับคุณ
tarรูปแบบส่วนหัวของมีลักษณะดังนี้:
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
เข้าใจว่ามีความชันที่สูงชันระหว่างความง่ายในการจัดการtarกับการดำเนินงานที่เรียบง่ายกับด้านที่ซับซ้อนกว่าของรูปแบบไฟล์เก็บถาวร ในขณะที่สิ่งที่ง่าย - เช่นการบรรจุไฟล์กลุ่มเล็ก ๆ ที่พิมพ์เป็นเนื้อเดียวกันด้วยกันหรือแม้กระทั่งการแยกไฟล์เก็บถาวรที่มีเฉพาะสมาชิกที่คุณสามารถคาดเดาได้ - สามารถทำได้อย่างง่ายดายด้วยเชลล์เชลล์เพียงไม่กี่ตัว
มันเป็นเรื่องยากโดยเฉพาะอย่างยิ่งเมื่อสมาชิกเหล่านั้นอาจมีข้อมูลไบนารีโดยพลการ - ซึ่งแน่นอนว่าจะ จำกัด การใช้งานที่เชื่อถือได้ของtr -s- และความยากลำบากนี้จะรวมเฉพาะเมื่อไฟล์ประเภทต่างๆอื่น ๆ นอกเหนือจากปกติและ / หรือ charsets อื่น ๆ ที่เก็บถาวรดั้งเดิมถูกสร้างขึ้นโดยการนำไปใช้กับรูปแบบแอพพลิเคชั่น idiosyncras ที่คุณไม่ได้เตรียมไว้ให้จัดการ และนี่เป็นเพียงการสัมผัสกับแง่มุมพื้นฐานที่เป็นมาตรฐานของtarประเภทไฟล์เก็บถาวร - เพิ่มส่วนหัวที่ขยายและส่วนขยายของรูปแบบและไฟล์ที่กระจายและการบีบอัดและ ... ดีโชคดีกับสิ่งเหล่านี้
กลับไปสู่พื้นฐานแม้ว่าขนาดมาตรฐานบันทึกสำหรับtarเก็บถาวรคือ 20 บล็อก - หรือ 10240 ไบต์ ustarแม้ว่าไฟล์เก็บถาวรจะถูกบล็อกในขนาดระเบียนมาตรฐานและมีเฉพาะไฟล์ประเภทมาตรฐานและส่วนหัวมาตรฐานเท่านั้นคุณควรข้ามจากส่วนหัวของสมาชิกไปยังส่วนหัวของสมาชิกโดยทำการอ่านตามsizeฟิลด์ส่วนหัวจนกว่าคุณจะพบสมาชิกที่ตรงกับ ซึ่งคุณแสวงหา เมื่ออ่านแล้วให้อ่านsizeหน่วยเป็นไบต์จากจุดเริ่มต้นออฟเซ็ตที่ส่วนท้ายของส่วนหัวสมาชิกของเป้าหมายของคุณ และนั่นคือไฟล์ของคุณ
แม้ว่าการข้ามส่วนหัวนั้นไม่ใช่เรื่องง่ายนัก sizeชนิดที่แตกต่างกันอย่างใดอย่างหนึ่งจะได้หรือไม่จะมีบล็อกข้อมูลที่เกิดขึ้นจริงต่อท้ายที่ตรงกับ ตัวอย่างเช่นไดเรกทอรีและลิงก์จะไม่มีบล็อกข้อมูลดังกล่าวมีเพียงคำอธิบายส่วนหัวและดังนั้นคุณจะต้องเตรียมการเพื่อตรวจสอบไฟล์ประเภทของส่วนหัวปัจจุบันก่อนที่จะตรวจสอบว่าคุณควรใช้sizeเขตข้อมูลกับสูตรข้ามของคุณหรือไม่
นอกจากนี้ปัจจัยบันทึกขนาด - ขึ้นอยู่กับว่าขนาดของสมาชิกที่เก็บถาวรซิงค์ได้ดีกับขนาดมาตรฐานบันทึก 10240 - อาจมีหรือไม่อาจจะเป็น 0 บล็อกเพิ่มเติมต่อท้ายแต่ละ และขนาดบันทึกสามารถประกาศ ณ เวลาที่สร้างการเก็บถาวร - และดังนั้นจึงอาจไม่ได้เป็น 20 บล็อกเลยแม้ว่าโดยสเป็คมันจะต้องถูกบล็อกในหน่วย 512 ไบต์เสมอ:
- USTAR
tarรูปแบบการแลกเปลี่ยน; ดูส่วนคำอธิบายขยาย เริ่มต้นบล็อคสำหรับรูปแบบนี้สำหรับไฟล์ที่เก็บอักขระพิเศษจะเป็น10240 การใช้งานที่จะสนับสนุนทุกบล็อคค่าน้อยกว่าหรือเท่ากับ32256ที่มีหลายรายการ512
ดังนั้นหากคุณกำลังทำงานกับtarไฟล์ที่อาจมีไฟล์ที่อาจมีข้อมูลไบนารีโดยพลการคุณจะต้องข้ามผ่านอัลกอริทึมของไฟล์และตามประเภทไฟล์ ข้อมูลจำเพาะพูดว่า:
sizeฟิลด์คือขนาดของไฟล์ใน octets ที่
- หาก
typeflagข้อมูลถูกตั้งค่าให้ระบุไฟล์ที่จะเป็นประเภท1 (กลิงค์ )หรือ2 (กเชื่อมโยงสัญลักษณ์ )ที่sizeสนามจะถูกระบุว่าเป็นศูนย์
- ถ้า
typeflagข้อมูลมีการตั้งค่าเพื่อระบุไฟล์ประเภท5 ( ไดเรกทอรี )ที่sizeสนามจะถูกตีความตามที่อธิบายไว้ภายใต้ความหมายของประเภทบันทึกว่า
- ไม่มีการบันทึกข้อมูลจะถูกเก็บไว้ตรรกะประเภท1 , 2หรือ5
- หาก
typeflagฟิลด์ถูกตั้งค่าเป็น3 ( ไฟล์อักขระพิเศษ ) , 4 ( บล็อกไฟล์พิเศษ )หรือ6 ( FIFO )ความหมายของsizeฟิลด์จะไม่ถูกระบุโดยปริมาตร POSIX.1-2008 นี้และไม่มีเร็กคอร์ดตรรกะข้อมูล เก็บไว้ในสื่อ
- นอกจากนี้สำหรับประเภท6ที่
sizeสนามจะถูกละเว้นเมื่ออ่าน
- หาก
typeflagตั้งค่าฟิลด์เป็นค่าอื่น ๆ จำนวนเร็กคอร์ดเชิงตรรกะที่เขียนหลังส่วนหัวจะต้องละเว้นเศษส่วนใด ๆ ในผลลัพธ์ของการหาร( (size+ 511 ) / 512 )
... และแน่นอนเมื่อพิจารณาถึงขนาดส่วนตัวของแต่ละส่วนหัว - ซึ่งเป็นบล็อกเพิ่มเติมต่อสมาชิก ดังนั้นคุณอาจข้ามการอ่านโดยอ่านจากส่วนหัวไปยังส่วนหัวจนกว่าคุณจะจับคู่ส่วนหัวที่คุณต้องการ ณ เวลานั้นคุณจะต้องตรวจสอบว่าระเบียนปัจจุบันเพียงอธิบายลิงก์ไปยังไฟล์ของคุณหรือไฟล์จริง . สิ่งนี้มีความเกี่ยวข้องโดยเฉพาะอย่างยิ่งเพราะเมื่อเพิ่มไฟล์เดียวกันในไฟล์เก็บถาวรหลายครั้งหลาย ๆ ไฟล์tarจะรวมเฉพาะส่วนหัวของลิงก์เพราะข้อมูลของไฟล์จริงสามารถพบได้ที่อื่นภายในคลังข้อมูล
เมื่อยืนยันแล้วว่าคุณจะต้องใช้การคำนวณกับchksumฟิลด์และยืนยันไฟล์ที่คุณคิดว่าเป็นไฟล์ที่คุณต้องการจริงๆ tar's chksumค่อนข้างง่าย though-:
- cksum
chksumฟิลด์จะเป็นมาตรฐาน ISO / IEC 646: 1991 เป็นตัวแทนก็อมาตรฐานของค่าฐานแปดของผลรวมที่เรียบง่ายของ octets ทั้งหมดในหัวบันทึกตรรกะ แต่ละ octet ในส่วนหัวจะถือว่าเป็นค่าที่ไม่ได้ลงชื่อ ค่าเหล่านี้จะถูกเพิ่มเข้าไปในจำนวนเต็มไม่ได้ลงนามเริ่มต้นเป็นศูนย์ความแม่นยำซึ่งไม่น้อยกว่า 17 บิต เมื่อคำนวณ checksum chksumจะถือว่าฟิลด์นั้นเป็นอักขระ<space>ทั้งหมด
แน่นอนคุณจะไม่จริงต้องดำเนินการใด ๆ ว่าเพราะtarอยู่แล้วสามารถทำอย่างนั้น - นั่นคือสิ่งที่มันไม่ - และดังนั้นคุณควรอาจจะเพียงแค่ใช้เพื่อค้นหาข้อมูลที่เก็บและแยกไฟล์สำหรับคุณ ในการทำเช่นนั้นมันจะไม่ทำอะไรแตกต่างไปจากที่คุณทำถ้าคุณรู้ว่าคุณกำลังทำอะไรอยู่ยกเว้นว่ามันอาจจะทำได้ดีกว่าและเร็วกว่าเพราะนั่นเป็นหน้าที่ของมัน แล้วทำไมคุณล่ะ