फ़ाइल का आकार शून्य कैसे हो सकता है?


173

बस कुछ मैं भागा और एक उचित स्पष्टीकरण के बारे में सोच भी नहीं सकता था। यदि मैं अपने पीसी पर एक खाली * .txt फ़ाइल बनाता हूं और फिर उसके आकार को देखता हूं, तो यह दिखाता है कि 0. यह कैसे संभव है? मेरा मतलब है कि भले ही फ़ाइल खुद खाली हो, फिर भी इसका कुछ आकार होना चाहिए, बस अपना नाम स्टोर करना है। इसे कैसे समझाया जा सकता है? (गैर ओएस विशिष्ट)


81
फ़ाइल का नाम फ़ाइल में गणना नहीं करता है, कि यह कैसे समझाया जा सकता है।
njzk2

123
मुझे कॉलेज में एक दोस्त की याद आई जिसने डिस्क कोटा के आसपास पाने के लिए फाइलनाम के रूप में टेक्स्ट स्टोर करने के लिए सॉफ्टवेयर का एक टुकड़ा लिखा था।
स्लीपबेटमैन

15
@ColeJohnson मैं अपने यू के कंप्यूटर लैब में 2000 में एक इंटर्न बैक था, और उपयोगकर्ता कोटा की गणना फाइलों के योग के रूप में की गई थी। तो फ़ाइल नाम के रूप में डेटा भंडारण वास्तव में qouta के आसपास मिलेगा। बिल्ली आप फ़ोल्डर्स में एक कार्यक्रम को बचा सकते हैं और यह आपके कोटा के खिलाफ नहीं गिना जाएगा।
माइंडविन

20
@ स्लेबेटमैन यह वह बिंदु है जहां प्रतिभा और पागलपन के बीच की रेखा धुंधली हो जाती है।
छप सिप

10
इसी तरह की एक तकनीक को एक संपीड़न चुनौती में प्रसिद्ध रूप से इस्तेमाल किया गया था ,
Oddthinking

जवाबों:


202

यह संभव है क्योंकि वास्तव में कोई फ़ाइल नहीं है। नाम और स्वामी के साथ केवल एक निर्देशिका प्रविष्टि है। निर्देशिका प्रविष्टि फ़ाइल से तार्किक रूप से अलग है। उदाहरण के लिए, एक ही फ़ाइल में एक से अधिक निर्देशिका में एक से अधिक नाम हो सकते हैं।

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


30
... हार्ड लिंक्स के रूप में भी जाना जाता है।
डेनियल बी

6
निर्देशिका में। अन्यथा, यदि एक ही फ़ाइल दो निर्देशिकाओं में थी और आपने इसे एक में बदल दिया, तो यह दूसरी निर्देशिका को संशोधित करेगी, जिसका कोई मतलब नहीं होगा। इसके अलावा, यह इस तरह से नहीं थे, एक निर्देशिका की सामग्री क्या होगी ?!
डेविड श्वार्ट्ज

14
अधिकांश UNIX- जैसे OS पर, FreeBSD और Linux की तरह, आप आसानी से एक निर्देशिका का आकार प्राप्त कर सकते हैं। जैसे ls -ld <directory>काम करेंगे।
डेविड श्वार्ट्ज

11
मुझे नहीं पता कि यह NTFS के वर्तमान संस्करण के लिए सच है, लेकिन शुरुआती संस्करण (जैसे NT3.x पर) निर्देशिका प्रविष्टि में बहुत छोटी फ़ाइलों के लिए डेटा संग्रहीत करेगा। फ़ाइल वस्तुतः मौजूद नहीं होगी।
जॉन रेनी

13
यह बिल्कुल सच नहीं है कि कोई फ़ाइल नहीं है, जब तक कि NTFS अन्य फाइल सिस्टम से बहुत अलग नहीं है। एक सामान्य यूनिक्स फाइल सिस्टम पर, अनुमतियाँ, मॉड-टाइम, और इसी तरह से एक इनकोड होता है। निर्देशिका प्रविष्टि अभी भी इस आईनोड को संदर्भित करती है। खाली फ़ाइल और गैर-रिक्त फ़ाइल के बीच एकमात्र अंतर ब्लॉक आवंटित करने के लिए सूचक है। एक खाली फ़ाइल में अपने ब्लॉक मैप के लिए NULL पॉइंटर के बराबर फाइलसिस्टम है, हालांकि, यह इंगित करने के लिए कि उसमें कोई डेटा ब्लॉक नहीं है। निर्देशिका प्रविष्टियाँ अनुमतियाँ और मॉड समय के साथ, यहां तक ​​कि खाली फ़ाइलों के लिए बंद नहीं की जाती हैं। उदाहरण के लिए XFS इनोड्स 256B हैं
पीटर कॉर्ड्स

82

"फ़ाइल आकार" का शब्दार्थ अर्थ आपके द्वारा उपयोग किए जा रहे से अलग है।

कई फ़ाइल आकार हैं जो सार्थक हैं। सबसे आम एक, और एक जिसे आप यहाँ देख रहे हैं, वह है "फ़ाइल में बाइट्स की संख्या।" यदि फ़ाइल एक खाली पाठ फ़ाइल है, तो इसमें वास्तव में 0 बाइट्स हो सकते हैं। यह संख्या प्रोग्रामर के लिए महत्वपूर्ण है क्योंकि हमें अक्सर एक फ़ाइल खोलने की आवश्यकता होती है, "सभी डेटा पढ़ें," और इसे बंद करें। हमें यह जानने की जरूरत है कि फाइल में कितने बाइट्स होंगे ताकि हम आगे की योजना बना सकें।

एक अन्य अर्थ उस तरह से उत्पन्न होता है जिस तरह से अधिकांश फाइल सिस्टम डेटा को स्टोर करते हैं। ज्यादातर फाइल सिस्टम ब्लॉक में डेटा स्टोर करते हैं। उदाहरण के लिए, फ़ाइल सिस्टम 64kB ब्लॉक में डेटा स्टोर कर सकता है, जिसका अर्थ है कि वह कभी भी कुछ भी आवंटित नहीं करेगा जो कि 64kB से अधिक नहीं है। यह अक्षम लगता है, लेकिन यह बहीखाता पद्धति को बहुत सरल बना सकता है, और अक्सर सरल का अर्थ है तेज।

एक तीसरा अर्थ, जिस पर आप टाल रहे हैं, वह फ़ाइल की उपस्थिति का वर्णन करने के लिए हार्डड्राइव पर आवश्यक बिट्स की वास्तविक संख्या होगी। इसमें वह जानकारी शामिल है जो आमतौर पर फ़ाइल से अलग संग्रहीत होती है। उदाहरण के लिए, लिनक्स में, "फ़ाइल नाम" की अवधारणा को इनोड में फाइल रखने वाली निर्देशिका के लिए इनोड में संग्रहीत किया जाता है (संपादित करें: टिप्पणियों से, तकनीकी रूप से यह निर्देशिका के डेटा में संग्रहीत होता है। जब मैंने यह लिखा था, तो मैं छोटे के बारे में सोच रहा था। -निर्देशित स्थिति। 156 बाइट्स से छोटा डेटा सीधे इनोड में संग्रहीत किया जा सकता है)। यह आमतौर पर उपयोग किया जाने वाला अर्थ नहीं है, क्योंकि यह आपके फ़ाइल सिस्टम के बहुत ही गहरे आंतरिक कामकाज को जाने बिना निर्धारित करना बहुत कठिन है (क्या आपने फ़ाइल पर सभी अनुमतियों को संग्रहीत करने के लिए आवश्यक स्थान के लिए खाता है?)। हालाँकि, यदि आपके पास 1,000,000 बाइट हार्ड ड्राइव है,


2
"फाइल वाले डायरेक्टरी के लिए इनकोड" क्या आपको इनोड के बजाय डायरेक्टरी के डेटा का मतलब नहीं है?
इनकोड

@ मेदीनोक गुड पॉइंट। मैं इनलाइन मामले के बारे में सोच रहा था जब उसने इनोड के भीतर डेटा संग्रहीत किया था, लेकिन मैंने वास्तव में यह देखने के लिए जांच नहीं की कि यह कितना हो सकता है! मैंने एक संपादन जोड़ा है।
Cort Ammon

एक्सट्रीम 4 के इनलाइन डेटा फीचर से संबंधित , यह सभी फाइल सिस्टमों के लिए किसी भी तरह से सार्वभौमिक नहीं है। इसके अतिरिक्त, यह फ़ाइल इनोड पर लागू होता है, निर्देशिका में नहीं। वे अलग हैं, निर्देशिकाओं में एक इनलाइन डेटा क्षमता भी है, लेकिन वे अलग-अलग विशेषताएं हैं। एक फाइल इनकोड का एक सेट आकार होता है, कम से कम ext4 के मामले में, इसलिए अनुमतियों का डेटा उपयोग अप्रासंगिक है। एक फ़ाइल डिस्क का उपयोग उपयोग में फाइल सिस्टम पर बहुत अधिक निर्भर है, इस उत्तर का तीसरा भाग केवल ext4 पर लागू होता है जहां तक ​​मैं बता सकता हूं, यह स्पष्ट नहीं किया गया है।
8

8
यदि आपके पास 1,000,000 बाइट हार्ड ड्राइव है, तो अपग्रेड के बारे में सोचना शुरू करने का समय हो सकता है।
नवजात

53

फ़ाइल नाम कहीं और संग्रहीत है।

आपकी डिस्क पर एक "फ़ाइल सिस्टम" होगा, बस यह चुनने के लिए एक विधि रखी जाएगी कि भौतिक डिस्क पर फ़ाइल नाम और फ़ाइलों का प्रतिनिधित्व और व्याख्या कैसे की जाती है।

अधिकांश विंडोज़ डिस्क पर आप "NTFS" (नई तकनीक फ़ाइल सिस्टम ") नामक फ़ाइल सिस्टम का उपयोग कर रहे होंगे, यह फ़ाइल सामग्री से अलग मास्टर फ़ाइल तालिका (MFT) में फ़ाइल नाम की जानकारी संग्रहीत करता है। मास्टर फ़ाइल तालिका पर विकिपीडिया लेख देखें ।

फ़ाइल अपने आप में लंबाई 0 बाइट्स की होगी, लेकिन एमएफटी में इसकी प्रविष्टि अभी भी कुछ स्थान पर कब्जा करेगी।


11
और NTFS के मामले में, विंडोज द्वारा रिपोर्ट की गई फ़ाइल का आकार और अधिकांश उपकरण वास्तव में फ़ाइल की मुख्य धारा का आकार है , जिसे हम फ़ाइल की सामग्री के रूप में देखते हैं। NTFS विभाजन पर संग्रहीत फ़ाइल अतिरिक्त डेटा वैकल्पिक डेटा धाराओं में संग्रहीत कर सकती है , और अभी भी 0 के आकार की सूचना है । यदि आप पूरी तस्वीर लेना चाहते हैं तो यह जानना एक अच्छा फाइलसिस्टम फीचर है :)
पावेल बुलवान

12

यह काफी दिलचस्प ontological सवाल है ...

फ़ाइल ही फ़ाइल की सामग्री है। यदि फ़ाइल में कोई सामग्री नहीं है, तो इसका आकार शून्य है। फ़ाइल का नाम फ़ाइल का उतना ही हिस्सा है जितना कि आपका अपना नाम शारीरिक रूप से आपका एक हिस्सा है (यानी, ऐसा नहीं है)।

जिस तरह आपका नाम लोगों के सिर (और आपके खुद के) में एक विचार के रूप में मौजूद है, जो भौतिक आपको संदर्भित / इंगित करता है, फ़ाइल नाम फ़ाइल सिस्टम की निर्देशिका ट्री में मौजूद है और यह फ़ाइल को संदर्भित / इंगित करता है।


7

(जवाब में थोड़ी देर ...)

एक फ़ाइल का आकार कैसे हो सकता है शून्य उपरोक्त उत्तरों द्वारा प्रदान की तुलना में थोड़ा अधिक जटिल है। इस सवाल को Win7 टैग किया गया है, लेकिन अन्य "सरल" फ़ाइल सिस्टम जैसे कि FAT या NTFS को देखना उपयोगी हो सकता है क्योंकि अवधारणाएं समान हैं।

डिस्क को "पता नहीं" है कि एक फाइल क्या है और एक निर्देशिका क्या है; यह छोटे ब्लॉक में सभी डेटा है। ओएस डेटा ब्लॉक के अर्थ के बीच अंतर करता है। पहले कुछ विशेष, लेकिन बाकी के ब्लॉक या तो डेटा के बारे में जानकारी रखते हैं (उदाहरण के लिए: फ़ाइल का नाम, फ़ाइल की लंबाई, डेटा को रखने वाला पहला डेटा ब्लॉक), या स्वयं डेटा।

एक निर्देशिका एक विशेष "फ़ाइल" है जिसका "डेटा" ओएस समझता है एक सूचना ब्लॉक है जिसमें फ़ाइलों के बारे में जानकारी है, न कि फाइलों की सामग्री। एक अच्छा सादृश्य एक भौतिक पुस्तकालय और कार्ड कैटलॉग है। डेटा ब्लॉक के रूप में सूचना ब्लॉकों के बारे में सोचें और डेटा ब्लॉक के रूप में अलमारियों (कार्ड कैटलॉग भी एक शेल्फ जैसी संरचना पर बैठता है)।

जब आप एक फ़ाइल बनाते हैं (UNIX touchकमांड के साथ कहते हैं ), OS पहली बार सूचना ब्लॉक (निर्देशिका) में एक प्रविष्टि बनाता है, जिसमें निम्न शामिल हैं:

  • नाम = My_File.txt
  • लंबाई = 0
  • डेटा ब्लॉक शुरू करना = एन / ए
  • अतिरिक्त जानकारी (स्वामी, अनुमतियां, बनाई / अपडेट / संशोधित तिथि), आदि

केवल अगर "लिखने" के लिए कुछ डेटा है तो क्या यह डेटा को संग्रहीत करने के लिए एक खाली डेटा ब्लॉक खोजने का प्रयास करता है। लेकिन डेटा ब्लॉक तय आकार में (32K कहते हैं) डिस्क के लिए सुविधाजनक है और ओएस को पढ़ने के लिए। यदि आप केवल "हैलो" लिखते हैं, तो अधिकांश ब्लॉक "खाली" है (वास्तव में शून्य नहीं हो सकता है, लेकिन जो पहले था वहां से कचरा हो सकता है), इसलिए तालिका भी अब आकार को लंबाई में अपडेट करती है (कहें 5 चार्ट + अंत फ़ाइल) ताकि आपको खराब सामान न मिले।

जब आप "फ़ाइल" को लंबाई> ब्लॉक आकार में अपडेट करते हैं, तो ओएस नए ब्लॉक को डेटा लिखता है और यह कहने के लिए डेटा ब्लॉक को अपडेट करता है कि फ़ाइल अगले ब्लॉक पर पहले (और इसी तरह) जारी है और लंबाई अपडेट की गई है। नई लंबाई (विवरण भिन्न)।

आपके साथ जो समाप्त होता है वह डेटा ब्लॉक (फ़ाइल सामग्री) की जंजीरों के बारे में जानकारी के साथ सूचना ब्लॉक (निर्देशिका या सूची) का एक संग्रह है।

तार्किक रूप से, यह यह भी बताता है कि क्यों एक ही फाइल सिस्टम पर एक फाइल तेजी से खिसक रही है जबकि एक कॉपी में लंबा समय लगता है। ओएस को केवल एक निर्देशिका (सूचना डेटा ब्लॉक) से प्रविष्टि को हटाने और दूसरे में जोड़ने के लिए 2 निर्देशिका ब्लॉकों को संपादित करना होगा। एक फ़ाइल को हटाएं: निर्देशिका ब्लॉक में प्रविष्टि को हटा दें, फ़ाइल डेटा ब्लॉक को पुनः प्राप्त करने के लिए खाली कर दें।

ps: सिर्फ इसलिए कि कार्ड कैटलॉग में किसी पुस्तक के लिए प्रविष्टि है, इसका मतलब यह नहीं है कि यह ठंडे बस्ते में है (शायद बाहर की जाँच की या खो गया); फ़ाइल का आकार ०।

pps: पुस्तकालय के अंदर एक गलत पुस्तक का अर्थ है खोज पुस्तकालय, या कंप्यूटर शब्दों में: chkdsk या मरम्मत डिस्क!

UNIX इनोड्स के बारे में पढ़कर या संस्करण नियंत्रण प्रणालियों (ClearCase, TFS, Git, आदि) की सराहना करते हुए एक बड़ी समझ को चमकाया जा सकता है, न केवल फाइलों और निर्देशिकाओं, बल्कि फाइलों के संस्करणों और यहां तक ​​कि निर्देशिकाओं के संस्करणों का प्रबंधन भी। ज्यादातर मामलों में, सब कुछ एक डेटाबेस में संग्रहीत किया जाता है और उपयोगकर्ता को शास्त्रीय निर्देशिका संरचना और फ़ाइलों के रूप में प्रस्तुत करने के लिए प्रस्तुत किया जाता है!


4

हमारे यहाँ कुछ उत्कृष्ट उत्तर हैं - मैं सिर्फ चित्र संस्करण (एक हज़ार शब्द और वह सब जोड़ना चाहता हूँ।)

यदि आप डिस्क डिफ्रैगमेंटिंग टूल से इसकी कल्पना करते हैं तो यह मेरी NTFS स्वरूपित हार्ड ड्राइव में से एक है। MFT (मास्टर फ़ाइल तालिका) बैंगनी में दिखाया गया है:

यहां छवि विवरण दर्ज करें

उस छोटे वायलेट वर्ग ने मेरे HD में मौजूद फाइलों की सूची का वर्णन किया है। मोटे शब्दों में, NTFS डिस्क के लिए, एक पुस्तक के लिए सामग्री तालिका क्या है; पृष्ठों के बजाय, यह डिस्क 1 के बाकी हिस्सों पर उनके भौतिक स्थान को इंगित करता है ।

शून्य-बाइट्स आकार वाली एक फ़ाइल को सामग्री प्रविष्टि तालिका के रूप में देखा जा सकता है, जो बिना किसी पृष्ठ के इंगित करती है:

यहां छवि विवरण दर्ज करें

प्रविष्टि वहां है, सूचीबद्ध है - लेकिन चूंकि कोई पृष्ठ इंगित नहीं किया गया है, इसलिए हम मान सकते हैं कि सामग्री अस्तित्वहीन है।

1 - निश्चित रूप से, यह उससे थोड़ा अधिक जटिल है; लेकिन क्षेत्र के नक्शे, दर्पण एमएफटी, आदि जैसे बिंदु इस प्रश्न के दायरे से बाहर हैं।


3

फ़ाइल सिस्टम की दुकान एक बहुत तरह के रूप में एक फ़ाइल के बारे में जानकारी की फ़ाइल नाम, फ़ाइल आकार, निर्माण के समय, उपयोग समय, संशोधित समय, बनाए गए उपयोगकर्ता, उपयोगकर्ता और समूह की अनुमतियों, टुकड़े, सूचक समूहों कि फ़ाइल की दुकान, कठिन / नरम लिंक, विशेषताओं के ... जिन्हें फ़ाइल मेटाडेटा कहा जाता है । जब आप उन लोगों की परवाह नहीं करते हैं और उनके बारे में नहीं जानते हैं, तो आप उन मेटाडेटा को फ़ाइल आकार में क्यों गिनते हैं? वे केवल फ़ाइल सामग्री के बारे में वास्तव में परवाह करते हैं

इसके अलावा प्रत्येक फाइल सिस्टम विभिन्न प्रकार के मेटाडेटा को संग्रहीत करता है जो डिस्क पर अलग-अलग मात्रा में जगह लेते हैं। उदाहरण के लिए, POSIX अनुमतियाँ NTFS की अनुमति से बहुत अलग हैं, और inodePOSIX में भी संख्याएँ हैं जो विंडोज पर मौजूद नहीं हैं। यहां तक ​​कि POSIX फाइलसिस्टम बहुत भिन्न होते हैं, जैसे कि ext3 32-बिट ब्लॉक एड्रेस के साथ, ext4 48-बिट के साथ, Btrfs 64-बिट और ZFS 128-बिट एड्रेस के साथ। तो आप उन मेटाडेटा को फ़ाइल आकार में कैसे गिनेंगे?

100-बाइट फ़ाइल के साथ एक और उदाहरण लें जिसका मेटाडेटा मौजूदा फाइलसिस्टम पर 56 बाइट खाता है। हम फाइल को दूसरे फाइल सिस्टम में कॉपी करते हैं और अब यह मेटाडेटा के 128 बाइट्स लेता है। हालाँकि फ़ाइल सामग्री बिल्कुल समान है , फ़ाइलों में बाइट्स की संख्या भी समान है। तो फाइल साइज़ को 156 बाइट्स के रूप में एक सिस्टम पर प्रदर्शित करना लेकिन दूसरे पर 228 बाइट्स बहुत भ्रामक और जवाबी हैं


1

फ़ाइल का आकार 0, कहने के समान है: मेरे पास इस 5पर शब्दों के साथ एक पेपर है। और दूसरे कागज पर, उस पर 0शब्द हैं। तो 0पूरी तरह से संभव है।

फ़ाइल का मेटा डेटा (निर्माण तिथि समय, अंतिम संशोधित दिनांक समय, फ़ाइल स्वामी, अनुमतियाँ), ये सभी संग्रहीत हैं जहाँ फ़ाइल आकार के भाग के रूप में शामिल नहीं किया गया है।


0

इसे सरल तरीके से समझें ... जब आप एक फ़ाइल बनाते हैं .. तो एक निर्देशिका प्रविष्टि उत्पन्न होती है जो आपके द्वारा प्रदान किए गए फ़ाइल नाम से पहचानी गई फ़ाइल के मेमोरी स्थान के लिए एक सूचक के रूप में काम करती है। जैसे ही आप अधिक से अधिक पॉइंटर्स बनाते हैं या फाइल्स कहते हैं, डायरेक्टरी का साइज़ बढ़ता जाता है .. जबकि फ़ाइल साइज़ तभी बढ़ेगा जब आप पॉइंटेड जगह पर यानी फाइल के अंदर ही ssome डेटा डालेंगे। तब तक आकार शून्य होगा। :)


यह वास्तव में एक टिप्पणी है - एक जवाब नहीं - और सिर्फ वही दोहराता है जो दूसरों ने कहा है।
जेकगॉल्ड

0

तो यह है कि यह कैसे काम करता है:

जैसे ही आप किसी फ़ाइल को वॉल्यूम पर बनाते हैं, वह NTFS माता फ़ाइल में $ MFT (मास्टर फ़ाइल टेबल) में एक फ़ाइल रिकॉर्ड बनाती है। चूंकि एमएफटी में एक एफआरएस (फाइल रिकॉर्ड सेगमेंट) मौजूद है, इसलिए आपको एक रिकॉर्ड दिखाई देगा। NTFS FileSystem के मामले में प्रत्येक फ़ाइल रिकॉर्ड डिफ़ॉल्ट रूप से 1 KB का होता है। लेकिन उस जगह पर केवल दावा किया जाता है यदि आप फ़ाइल के अंदर कुछ जानकारी संग्रहीत करते हैं। भले ही आप केवल एक पत्र "a" लिखते हैं, यह देखते हुए कि यह एक पाठ फ़ाइल है, यह 1 KB स्थान का दावा करेगा क्योंकि यह FRS का डिफ़ॉल्ट आकार है। पत्र "ए" उस एफआरएस के डिफ़ॉल्ट और अनाम डेटा स्ट्रीम में जाता है, $ डेटा जो एक विशेषता है जहां आप सभी डेटा जाते हैं यदि आपके पास एडीएस (वैकल्पिक डेटा स्ट्रीम) नहीं है।

अगर आपको कोई सवाल आता है तो मुझे बताएं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.