लिनक्स में शून्य बाइट्स के साथ एक फ़ाइल बनाने की अवधारणा क्या है?

Question

यदि मैं निम्नलिखित कार्य करता हूं:

touch /tmp/test

और फिर प्रदर्शन करते हैं

ls -la /tmp/

मैं डायरेक्टरी में 0 बाइट्स वाली testफाइल देख सकता था ।

लेकिन ऑपरेटिंग सिस्टम 0 बाइट्स की अवधारणा को कैसे संभालता है । अगर मैं इसे आम शब्दों में कहूँ तो:

0 बाइट्स कोई मेमोरी नहीं है, इसलिए कुछ भी नहीं बनाया गया है।

एक फ़ाइल का निर्माण, कम से कम कुछ निश्चित मेमोरी की आवश्यकता होनी चाहिए या नहीं ?

Comments

क्रॉस-साइट डुप्लिकेट: कोई फ़ाइल आकार शून्य कैसे हो सकता है? , en.wikipedia.org/wiki/Zero-byte_file

— phuclv

Answer 1

एक फ़ाइल (लगभग) तीन अलग चीजें हैं:

• एक "इनोड", एक मेटाडेटा संरचना जो फ़ाइल, अनुमतियों और डिस्क पर ब्लॉक की एक सूची का ट्रैक रखती है जिसमें वास्तव में डेटा होता है।
• एक या अधिक निर्देशिका प्रविष्टियाँ (फ़ाइल नाम) जो उस आईनोड को इंगित करती हैं
• डेटा के वास्तविक ब्लॉक स्वयं

जब आप एक खाली फ़ाइल बनाते हैं, तो आप केवल इनोड बनाते हैं और एक निर्देशिका प्रविष्टि जो उस इनोड की ओर इशारा करती है। विरल फाइलों के लिए भी ( dd if=/dev/null of=sparse_file bs=10M seek=1)।

जब आप किसी मौजूदा फ़ाइल में हार्डलिंक बनाते हैं, तो आप बस अतिरिक्त निर्देशिका प्रविष्टियाँ बनाते हैं जो उसी इनोड की ओर इशारा करती हैं।

मैंने यहां चीजों को सरल बनाया है, लेकिन आपको इसका विचार है।

Comments

अच्छी तरह से कहा गया है। अपने "हार्ड-लिंक" पैराग्राफ द्वारा एक छोटे से छोटे को बढ़ावा देने के दौरान: यदि कोई खाली फाइल के लिए एक हार्ड-लिंक बनाता है, जिसकी आपके पास कोई ब्लॉक की सूची नहीं है, तो ब्लॉक का लिंक (उसी) सूची में कैसे हो सकता है? जो मौजूद नहीं है?

— थियोफ्रेस्टस

@ Theophrastus अच्छी बात है। मैंने चीजों को सरल बनाने के लिए अपना संभव बनाया है। वास्तव में ब्लॉक की सूची और निर्देशिका प्रविष्टियों के बीच, फ़ाइल से संबंधित मेटाडेटा हैं (एक इनोड संख्या द्वारा संदर्भित) और जिसमें फ़ाइल विशेषताएँ (स्वामी, अनुमतियाँ, ...) और विस्तारित विशेषताएँ हैं। ब्लॉक की सूची में है। इसलिए सभी निर्देशिका प्रविष्टियाँ सीधे ब्लॉक (FAT तरीके) की सूची को इंगित नहीं करती हैं, लेकिन मेटाडेटा को।

— xhienne

तीन अलग-अलग चीजें होनी चाहिए: उन ब्लॉकों की एक सूची जिसमें डेटा शामिल है; खुद को ब्लॉक करता है ; और एक निर्देशिका प्रविष्टि (या प्रविष्टियाँ) जो ब्लॉक की सूची को इंगित करती है।

— वाइल्डकार्ड

@Wildcard मैंने इसे तीन चीजों को बनाने के लिए एक संपादन प्रस्तुत किया है, और इसके नाम से इनोड को संदर्भित किया है। इनोड और निर्देशिका दोनों मेटाडेटा हैं; लेकिन वे मेटाडेटा के विभिन्न प्रकार हैं। फ़ाइल में हमेशा एक इनकोड होता है, और कम से कम एक निर्देशिका प्रविष्टि होती है। उस कोड में डेटा ब्लॉक की एक खाली सूची शामिल हो सकती है।

— मोंटी हार्डर

@Wildcard भले ही आप एक शुरुआत कर रहे हैं, एक अंतर और एक निर्देशिका के बीच अंतर को समझना महत्वपूर्ण है। जब कोई "एक निर्देशिका नाम" की अनुमति / स्वामित्व को बदलता है और सोचता है कि एक ही इनोड के अन्य लिंक पुराने अनुमतियों / स्वामित्व को बनाए रखेंगे, तो कुछ बहुत खराब हो सकता है। हमें इस बात की जानकारी नहीं देनी चाहिए कि इनोड्स डायरेक्ट ब्लॉक, इनडायरेक्ट ब्लॉक, डबल और ट्राइ-इनडायरेक्ट ब्लॉक को कैसे रेफर करते हैं, यह जानने के लिए कि यह ब्लॉक की सूची है। या कि कोई सूची खाली हो सकती है।

— मोंटी हार्डर

Answer 2

touchएक पैदा करेगा inode , और ls -iया statinode बारे में सूचना दिखाएगा:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

ध्यान दें कि test0 ब्लॉक का उपयोग करता है। प्रदर्शित डेटा को संग्रहीत करने के लिए, इनोड कुछ बाइट्स का उपयोग करता है। उन बाइट्स को इनोड टेबल में संग्रहित किया जाता है। एक इनोड संरचना के उदाहरण के लिए ext2 पृष्ठ देखें ।

Answer 3

ls(या अच्छी तरह से, stat(2)सिस्टम कॉल) आपको फ़ाइल की सामग्री का आकार बताता है । बहीखाता पद्धति के लिए फाइलसिस्टम की कितनी जगह है, इसका हिस्सा नहीं है, और कार्यान्वयन विवरण के रूप में, यह ऐसा कुछ नहीं है जो सामान्य रूप से कार्यक्रमों की देखभाल या यहां तक ​​कि पता होना चाहिए । कार्यान्वयन विवरण को दृश्यमान बनाने से फाइलसिस्टम अमूर्तता कम उपयोगी होगी।

Answer 4

फ़ाइल, स्वयं, किसी भी स्थान पर कब्जा नहीं करती है, लेकिन फ़ाइल सिस्टम फ़ाइल नाम, स्थान, उस पर अधिकार और इस तरह का भंडारण करता है।

Comments

यदि आप निर्देशिका प्रविष्टि के कब्जे वाले स्थान को देखते हैं, यदि आपके पास एक निर्देशिका है जिसमें एक हजार फाइलें हैं जो 0 बाइट्स के आकार की हैं, तो निर्देशिका एक निर्देशिका प्रविष्टि से बड़ी होगी, जिसमें सिर्फ 2 विशाल फाइलें हैं।

— मार्क स्टीवर्ट

यह उल्लेख करने के लिए कि एक फ़ाइल एक अमूर्त अवधारणा है जो किसी डिस्क पर इसके भौतिक प्रतिनिधित्व के साथ कसकर जुड़ी नहीं है।

— फ्लोरियन कैस्टेलन

Answer 5

सरल उत्तर: क्योंकि यह इस तरह परिभाषित है।

लंबा उत्तर: यह इस तरह परिभाषित किया गया है क्योंकि कुछ ऑपरेशन वैचारिक रूप से सरल हैं:

• यदि किसी फ़ाइल में 20 अक्षर "A" हैं, और आप सभी "A" s हटाते हैं, तो फ़ाइल 20 बाइट्स छोटी हो जाएगी। एक फ़ाइल पर एक ही ऑपरेशन जिसमें सिर्फ "AAAAAAAAAAAAAAAAAAAAAA" शामिल था, एक लुप्त फ़ाइल के विशेष मामले से निपटना होगा।
• व्यावहारिक रूप से, किसी टेक्स्ट फ़ाइल की अंतिम पंक्ति को हटाने के लिए विशेष आवरण होना चाहिए।
• पाठ संपादक जो नियमित रूप से एक बैकअप बनाते हैं, को उस स्थिति से निपटने के लिए विशेष-केस कोड की आवश्यकता होगी जो उपयोगकर्ता अंतिम पंक्ति को हटा सकता है, दोपहर के भोजन पर जा सकता है, फिर वापस आकर दूसरी पंक्ति जोड़ सकता है। आगे की जटिलताएँ उत्पन्न होती हैं यदि कुछ अन्य उपयोगकर्ताओं ने उस समय में इस नाम से एक फ़ाइल बनाई।

आप और अधिक कार्य कर सकते हैं: * त्रुटि लॉग फाइलें खाली हो जाती हैं, यदि और केवल त्रुटि होने पर भरा जाना है। * यह पता लगाने के लिए कि कितनी त्रुटियां हुईं, आप लॉग फाइलों में लाइनों की संख्या गिनते हैं। यदि लॉग फ़ाइल खाली है, तो त्रुटियों की संख्या शून्य है, जो सही अर्थ बनाती है। * कभी-कभी आप उन फाइलों को देखते हैं जहां सभी प्रासंगिक पाठ फ़ाइल नाम में होते हैं, जैसे this-is-the-logging-directory। यह इंस्टालेशन के बाद खाली निर्देशिकाओं को हटाने से अधिक व्यवस्थापकों को रोकता है, और यह उन बग्स को भी रोकता है जहां कोई प्रोग्राम या उपयोगकर्ता गलती से एक फाइल बनाता है जहां प्रोग्राम बाद में एक निर्देशिका देखना चाहता है। gitकार्यक्रम (और अन्य) खाली निर्देशिका ध्यान करते हैं, और एक परियोजना / व्यवस्थापक / उपयोगकर्ता एक रिकॉर्ड निर्देशिका मौजूद है कि भले ही यह कोई उपयोगी सामग्री (अभी तक) है है के लिए करना चाहता है, तो आप एक खाली फ़ाइल का नाम देख सकते हैंemptyया empty.directory।

कोई भी ऑपरेशन अधिक जटिल नहीं होता है:

• कॉन्टेनेटिंग फाइलें: यह एक खाली फाइल के साथ सिर्फ एक ऑप है।
• किसी फ़ाइल में स्ट्रिंग की खोज करना: यह "यदि शब्द खोज शब्द से छोटा है, तो यह खोज शब्द समाहित नहीं कर सकता है" के मानक मामले से आच्छादित है।
• फ़ाइल से पढ़ना: प्रोग्राम को फ़ाइल के अंत से टकराने से निपटने की ज़रूरत है इससे पहले कि वे उम्मीद करते हैं, इसलिए फिर से एक शून्य-लंबाई फ़ाइल के मामले में प्रोग्रामर के लिए अतिरिक्त सोच शामिल नहीं है: वह सिर्फ एंड-ऑफ हिट करेगा -शुरुआत से।

फ़ाइलों के मामले में, "एक फ़ाइल कहीं दर्ज की गई है" पहलू (इनोड और / या फ़ाइल नाम) उपरोक्त विचारों के शीर्ष पर आता है, लेकिन फ़ाइल सिस्टम ऐसा नहीं करेगा यदि खाली फाइलें बेकार थीं।

सामान्य तौर पर, फ़ाइल नामों से संबंधित को छोड़कर उपरोक्त सभी कारण अनुक्रमों पर लागू होते हैं। अधिकांश विशेष रूप से स्ट्रिंग्स के लिए, जो वर्णों के अनुक्रम हैं: कार्यक्रमों के अंदर शून्य-लंबाई के तार आम हैं। स्ट्रिंग को आमतौर पर उपयोगकर्ता स्तर पर अस्वीकृत कर दिया जाता है यदि वे समझ में नहीं आते हैं: एक फ़ाइल नाम एक स्ट्रिंग है, और अधिकांश फ़ाइल सिस्टम फ़ाइल नाम के रूप में एक रिक्त स्ट्रिंग की अनुमति नहीं देते हैं; आंतरिक रूप से, टुकड़ों से फ़ाइल नाम बनाते समय, प्रोग्राम में एक टुकड़े के रूप में एक खाली स्ट्रिंग हो सकती है।

Answer 6

सबसे सरल सादृश्य का उपयोग करना:

चलो, एक गिलास पानी के साथ एक फ़ाइल की तुलना करें।

t टच / टैम्प / टेस्ट ’एक खाली गिलास बनाने के लिए बहुत पसंद है, जिसमें कोई भी पानी न हो। ग्लास खाली है, इसलिए इसका आकार शून्य है। लेकिन कांच मौजूद है।

फाइल सिस्टम parlance में, ग्लास मेटा-डेटा है, जबकि ग्लास की सामग्री डेटा है। मेटा-डेटा में पिछली पोस्ट में वर्णित सभी प्रकार के सामान शामिल हैं।

शून्य-आकार की फाइलें उपयोगी हो सकती हैं। एक उदाहरण उन्हें ब्रेडक्रंब के रूप में उपयोग कर रहा है, जहां इसका मात्र अस्तित्व किसी प्रकार की स्थिति को इंगित करने के लिए इस्तेमाल किया जा सकता है (यानी, यदि फ़ाइल मौजूद है: तो कुछ करें; यदि नहीं: अनदेखा करें)।

Answer 7

इसके बारे में इस तरह से सोचें: यह कहें कि एक प्रोग्राम आपके सर्वर पर भेजे गए SQL प्रश्नों को ट्रैक कर रहा है। कार्यक्रम यह इंगित करना चाहता है कि यह एक सादे पाठ फ़ाइल में अनुरोधों को लॉग कर रहा है, लेकिन अभी तक कोई अनुरोध लॉग नहीं किया गया है। ऐसा क्या दिखना चाहिए? मेरा तर्क है कि यह एक शून्य आकार की फ़ाइल होनी चाहिए /var/log/acme-sql-server/queries.log। इस तरह, आप यह पता लगा सकते हैं कि लॉगिंग कब शुरू हुई (फ़ाइल का निर्माण समय), जब इसे अंतिम बार अपडेट किया गया था (यानी जब इसे बनाया गया था), कितने प्रश्न रिकॉर्ड किए गए थे (फाइल में 0 नंबर की नई संख्या), और लॉगिंग कौन कर रहा है (एक्मे SQL सर्वर)। इस तरह के मामलों के लिए, यह एक खाली फ़ाइल की अवधारणा के लिए उपयोगी है जो फिर भी किसी विशेष स्थान पर मौजूद है।