ओह, लेकिन यह एक फ़ाइल के भीतर फ़ाइल की सामग्री के बारे में एक प्रश्न है 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फ़ील्ड इनपुट के NUL सीमांकित रेखा के 1,2,13 फ़ील्ड को इंगित करते हैं । इस तरह की चीजें आसान होती हैं जब फ़ाइल में केवल पाठ फ़ाइलें होती हैं क्योंकि रिकॉर्ड रिकॉर्ड सीमांकक (जैसा कि प्रत्येक 512 बाइट्स के बाद एक बार हो सकता है) को बस एक एकल NUL तक निचोड़ा जा सकता है और छीन लिया जा सकता है - आपको घटनाओं को गिनने की आवश्यकता के बिना।tartar
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- और यह कठिनाई केवल तब होती है जब आपके मूल निवासी के अलावा अन्य नियमित और / या चारसेट्स के अलावा अन्य प्रकार की फ़ाइलों का उपयोग किया जाता है और / या। मूल संग्रह को एक ऐसे स्वरूप द्वारा तैयार किया गया था जिसे प्रारूप एप्लिकेशन आईडीओसिंक्रासेस के साथ कार्यान्वित किया जाता है जिसे आप हैंडल करने के लिए तैयार नहीं हैं। और यह केवल tarसंग्रह प्रकार के मूल, मानकीकृत पहलुओं पर छू रहा है - विस्तारित हेडर और प्रारूप एक्सटेंशन और विरल फ़ाइलों और संपीड़न और ... अच्छी तरह से, उन लोगों के साथ शुभकामनाएँ जोड़ें।
मूल बातों पर वापस जाएं, हालांकि, एक अभिलेख के लिए मानक रिकॉर्डtar 20 ब्लॉक है - या 10240 बाइट्स। मानक अभिलेख-आकार पर अवरुद्ध संग्रह को देखते हुए और केवल मानक फ़ाइल प्रकार और मानक ustarहेडर युक्त होते हैं, हालाँकि, आपको सदस्य-हेडर से सदस्य-हेडर से sizeहेडर फ़ील्ड के अनुसार रीडिंग करके तब तक छोड़ देना चाहिए जब तक कि आप एक सदस्य के लिए मेल नहीं खाते। जो आप चाहते हैं। एक बार वहाँ, sizeअपने लक्ष्य सदस्य हेडर की पूंछ पर ऑफसेट ऑफसेट से बाइट्स में पढ़ें । और वो आपकी फाइल है।
हेडर पर लंघन करना बहुत आसान नहीं है, हालाँकि। अलग-अलग प्रकार के या तो वास्तविक डेटा ब्लॉक नहीं होंगे, जो इसके अनुरूप हों size। उदाहरण के लिए, निर्देशिकाओं और लिंक में ऐसा कोई डेटा ब्लॉक नहीं होगा, केवल एक हेडर विवरण होगा, और इसलिए आपको यह पता लगाने से पहले वर्तमान हेडर के फ़िलेटाइप को सत्यापित करने के लिए तैयार होना चाहिए कि क्या आपको अपने sizeफ़ील्ड को अपने छोड़ें सूत्र पर लागू करना चाहिए या नहीं।
इसके अलावा, रिकॉर्ड- आकार के कारक - इस बात पर निर्भर करता है कि संग्रह-सदस्यों के आकार 10240 मानक रिकॉर्ड के साथ अच्छी तरह से सिंक हुए हैं या नहीं, प्रत्येक में संलग्न अतिरिक्त 0-ब्लॉक हो सकता है या नहीं। और रिकॉर्ड- आकार को संग्रह निर्माण समय पर घोषित किया जा सकता है - और इसलिए यह 20 ब्लॉक भी नहीं हो सकता है, हालांकि, कल्पना से, इसे हमेशा 512-बाइट इकाइयों पर अवरुद्ध किया जाना चाहिए:
- ustar
tarविनिमय प्रारूप; अतिरिक्त विवरण अनुभाग देखें। चरित्र विशेष संग्रह फ़ाइलों के लिए इस प्रारूप के लिए डिफ़ॉल्ट अवरोधन 10240 होगा । कार्यान्वयन 512 के गुणक से कम या 32256 के बराबर सभी अवरोधक मूल्यों का समर्थन करेगा ।
इसलिए यदि आप एक ऐसी tarफ़ाइल के साथ काम कर रहे हैं जिसमें ऐसी फाइलें हो सकती हैं जिनमें मनमाने ढंग से बाइनरी डेटा हो सकता है तो आपको एल्गोरिथम रूप से फ़ाइल के माध्यम से छोड़ना होगा, और फ़िलाटाइप के अनुसार। युक्ति कहती है:
sizeक्षेत्र ओक्टेट्स में फ़ाइल का आकार है।
- यदि
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के chksumकाफी सरल, हालांकि है:
- cksum
- यह
chksumफ़ील्ड ISO / IEC 646: 1991 होगा, जिसमें हेडर लॉजिकल रिकॉर्ड में सभी ऑक्टेट के साधारण योग के अष्टाधारी मूल्य का मानक IRV था। हेडर में प्रत्येक ऑक्टेट को एक अहस्ताक्षरित मान के रूप में माना जाएगा। इन मानों को एक अहस्ताक्षरित पूर्णांक में जोड़ा जाएगा, जिसे शून्य से आरंभ किया जाएगा, जिसकी सटीकता 17 बिट से कम नहीं है। चेकसम की गणना करते समय, chksumफ़ील्ड को ऐसा माना जाता है जैसे कि यह सभी <space> वर्ण थे।
बेशक, आपको वास्तव में ऐसा कुछ भी नहीं करना होगा , क्योंकि tarवह पहले से ही ऐसा कर सकता है - यही वह करता है - और इसलिए आपको इसका उपयोग केवल संग्रह को खोजने और आपके लिए फ़ाइल निकालने के लिए करना चाहिए। ऐसा करने से आप कुछ अलग नहीं करेंगे, अगर आप जानते हैं कि आप इसके बारे में क्या जानते थे, सिवाय इसके कि यह शायद बेहतर और तेज़ होगा क्योंकि यही इसका काम है। और वैसे भी, तुम क्यों चाहिए?