क्या मेटाडेटा किसी भी आकार पर कब्जा नहीं करता है?

Question

मैंने एक टेक्स्ट फाइल में 4096 अक्षर डाले और उसे सेव किया। हर अक्षर 1 बाइट है। टेक्स्ट फाइल का साइज 4K बाइट होना चाहिए। जैसा कि आप नीचे देखते हैं कि यह ठीक है:

मैं अपनी फ्लैश मेमोरी को अपने कंप्यूटर से जोड़ता हूं। फ़्लैश मेमोरी पर मुक्त स्थान 1,717,518,336बाइट्स है :

मैंने अपनी फ़्लैश मेमोरी में फ़ाइल की एक कॉपी बनाई। और फिर से खाली स्थान पर एक नज़र डालें। यह 1,717,514,240बाइट्स मुक्त स्थान है:

आइए देखें कि क्या अंतर है:

1,717,518,336 - 1,717,514,240 =4096 बाइट्स

---

मेरा प्रश्न :

Q1:

जैसा कि आप ऊपर की अंतिम तस्वीर में देखते हैं, एकमात्र स्थान जो फ़ाइल फ़्लैश पर कब्जा कर लेता है, वह अपनी सामग्री [वर्ण] के लिए स्थान है। तो मेटाडाटा फ़ाइल कहाँ है?

मेरा मतलब है, जब मैं फ़ाइल को दूसरे कंप्यूटर पर ले जाता हूं, तो यह फ़ाइल का नाम, फ़ाइल का मालिक, दिनांक और संशोधित और कैसे समझ सकता है ...?

क्या यह किसी भी आकार पर कब्जा नहीं करता है? !!

Q2:

क्या मैं फ़्लैश मेमोरी में मेटाडेटा फ़ाइल देख सकता हूँ?

अपने समय और विचार की सराहना करें।

Comments

मेटाडाटा फाइलसिस्टम में ही समाहित होगा। यह Windows द्वारा रिपोर्ट की गई फ़ाइल आकार का हिस्सा नहीं है। इसके अलावा FAT32 और NTFS मेटाडेटा अलग होगा।

— रामहाउंड

@Ramhound जब मैं टेक्स्ट फाइल को फ्लैश मेमोरी में ले जाता हूं, तो उसकी मेटाडेटा फाइल भी फ्लैश मेमोरी में चली जाती है, है ना? मैं इसे कैसे देख सकता हूँ?

— TheGoodUser

संभावित डुप्लिकेट कैसे फ़ाइल मेटाडेटा विंडोज में संग्रहीत हैं? , फ़ाइल नाम कैसे संग्रहीत किए जाते हैं?

— and31415

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

— जो

संक्षिप्त उत्तर: यह जगह लेता है, लेकिन इसे फ़ाइल आकार के हिस्से के रूप में नहीं गिना जाता है।

— user253751

Answer 1

हां, मेटाडेटा स्थान घेरता है। NTFS पर यह विशिष्ट होने के लिए 1024 बाइट्स पर कब्जा कर लेता है। हालाँकि, जानकारी फ़ाइल में संग्रहीत नहीं है, लेकिन मास्टर फ़ाइल तालिका MFT में। विशेष रूप से एमएफटी रिकॉर्ड # 4 में $AttrDef।

देखें इस टेकनेट लेख जानकारी के लिए: तालिका 3.5 सभी MFT रिकॉर्ड में परिभाषित किया गया है।

जब NTFS के साथ एक वॉल्यूम स्वरूपित किया जाता है, तो एक मास्टर फ़ाइल टेबल (MFT) फ़ाइल और मेटाडेटा के अन्य टुकड़े बनाए जाते हैं। मेटाडाटा वे फाइलें हैं जो NTFS फाइल सिस्टम संरचना को लागू करने के लिए उपयोग करता है। NTFS मेटाडेटा फ़ाइलों के लिए MFT के पहले 16 रिकॉर्ड रखता है।

NTFS प्रत्येक फ़ाइल के लिए एक फ़ाइल रिकॉर्ड और NTFS वॉल्यूम पर बनाए गए प्रत्येक निर्देशिका के लिए एक निर्देशिका रिकॉर्ड बनाता है। एमएफटी में ही एमएफटी के लिए एक अलग फ़ाइल रिकॉर्ड शामिल है। ये फ़ाइल और निर्देशिका रिकॉर्ड MFT ​​पर संग्रहीत हैं। फ़ाइल की विशेषताओं को एमएफटी में आवंटित स्थान पर लिखा गया है। फ़ाइल विशेषताओं के अलावा, प्रत्येक फ़ाइल रिकॉर्ड में एमएफटी में फ़ाइल रिकॉर्ड की स्थिति के बारे में जानकारी होती है।

ध्यान दें कि अन्य फ़ाइल सिस्टम मेटाडेटा के साथ अलग तरीके से व्यवहार कर सकते हैं और कर सकते हैं।

EDIT: यह टिप्पणी अनुभाग में बताया गया है कि यह उत्तर बिंदु याद कर रहा है क्योंकि ओपी ने एफएटी 32 फाइल सिस्टम पर मेटाडाटा के लिए कहा था, न कि एनटीएफएस। अगर मुझे पता था कि कैसे, मैं "सही उत्तर" विशेषता को हटा दूंगा। इसलिए मैं अतिरिक्त जानकारी प्रदान करता हूं जो FAT32 के संबंध में प्रश्न का उत्तर देता है।

FAT32 एफएस के मूल फ़ोल्डर से एक पेड़ बनाने, फ़ाइल या फ़ोल्डर के मूल फ़ोल्डर में एक प्रविष्टि में प्रत्येक फ़ाइल और फ़ोल्डर के लिए दृश्यता या संशोधन समय जैसे साधारण मेटाडेटा को बचाता है। जैसा कि NTFS के संबंध में बताया गया है कि यह एक फ़ाइल नहीं है, लेकिन फ़ोल्डर डेटा संरचना के भीतर सहेजी गई है । मूल रूप से प्रविष्टि 32 बाइट बड़ी थी और इसमें निम्नलिखित विशेषताएं थीं:

Name (8.3) xxxxxxxx.yyy. (88 bits)

Attribute byte (8 bits of information, described later in this section).

One reserved byte.

Create time (24 bits).

Create date (16 bits).

Last access date (16 bits).

Two reserved bytes.

Last modified time (16 bits).

Last modified date (16 bits).

Starting cluster number in the file allocation table (16 bits).

File size (32 bits).

इस Microsoft Technet लेख से सूची ली गई और FAT16 से संबंधित है। चूंकि एफएटी 32 का क्लस्टर आकार 32 बिट्स हो सकता है और फाइलों का नाम 8.3 से अधिक हो सकता है, तालिका पूरी तरह से सटीक नहीं है। लंबे फ़ाइल नाम और बड़े डिस्क को समायोजित करने के लिए FAT32 कुछ व्यवहार को संशोधित करता है जिसे यहाँ विकिपीडिया में पढ़ा जा सकता है लेकिन मूल विचार रखता है।

Comments

मेटाडेटा को देखने और किसी भी विस्तार को खोजने के लिए आप Sysinternal सुइट के NTFSinfo का उपयोग कर सकते हैं। आप इसे यहाँ डाउनलोड कर सकते हैं: Technet.microsoft.com/en-us/sysinternals/default आसपास कई मेटाडेटा संपादक हैं, लेकिन मैं किसी एक की सिफारिश नहीं कर सकता क्योंकि मैंने उनका उपयोग नहीं किया है।

— बंजेंसन

@ TheGoodUser-Sp मेटाडेटा, NTFS पर कम से कम, पारंपरिक अर्थों में "एक फ़ाइल" में संग्रहीत नहीं है, जो कि मुझे वह छाप है जो आप ढूंढ रहे हैं। वहाँ कहीं नहीं है दूर \ windows फ़ोल्डर में tucked है कि हम सब सिर्फ तुम्हारे बारे में नहीं बता रहे हैं; फ़ाइल मेटाडेटा ही फाइलसिस्टम का एक अभिन्न हिस्सा है।

— रोब मोइर

इस स्थिति में फ्लैश ड्राइव को FAT-32 के रूप में स्वरूपित किया जाता है। तो मेटाडा फ़ाइल आवंटन तालिका (FAT) en.wikipedia.org/wiki/File_Allocation_Table

— jnovacho

यह ध्यान रखना महत्वपूर्ण है कि एनटीएफएस और एफएटी के लिए आवंटन तालिकाओं का प्रचार किया जाता है। यह प्रारूप से प्रारूप में भिन्न होता है, लेकिन कई क्षेत्रों में आमतौर पर खाली प्रचारित ब्लॉकों के साथ कब्जा कर लिया जाता है जिनका उपयोग विखंडन को कम करने के लिए मेटाडेटा के भंडारण के लिए किया जाता है।

— कासलाई

आपको क्या लगता है कि मेटाडेटा निश्चित आकार है? अभिगम नियंत्रण सूची निश्चित रूप से जटिलता में काफी भिन्न हो सकती है; मैं यह देखने में विफल रहता हूं कि यह 1024 बाइट्स में कैसे फिट हो सकता है (अन्य सभी मेटाडेटा जैसे एक्सेस और संशोधन के समय के साथ)

— बेन Voigt

Answer 2

क्या यह किसी भी आकार पर कब्जा नहीं करता है? !!

हां, लेकिन यह एक बड़े पूर्व-आवंटित ब्लॉक में एक छोटी प्रविष्टि है। वह ब्लॉक आपकी डिस्क के "उपयोग" भाग में गिना जाता है। उस ब्लॉक के अंदर एक प्रविष्टि जोड़ने से ब्लॉक को विस्तारित करने की आवश्यकता नहीं होती है।

फाइलसिस्टम के आधार पर, अंततः बहुत सारे फिलनेम के जुड़ने के बाद ब्लॉक को किसी तरह भरा और बढ़ाया जाएगा।

क्या मैं फ़्लैश मेमोरी में मेटाडेटा फ़ाइल देख सकता हूँ?

आसानी से नहीं

जैसा कि रुस्लान और ब्लोर्बर्ग ने टिप्पणी की थी। आप हेक्सडी जैसे एक हेक्स दर्शक स्थापित कर सकते हैं जो आपको कच्चे फाइल सिस्टम डेटा को देखने (और संपादित करने - बहुत सावधान रहने) की अनुमति देगा। लेकिन आपको यह व्याख्या स्वयं करनी होगी कि कौन सी बाइट्स किस फाइल सिस्टम संरचनाओं से संबंधित हैं। उसके लिए आपको फ्लैश डिस्क पर उपयोग किए जाने वाले विशिष्ट फाइल सिस्टम के कुछ अच्छे प्रलेखन की आवश्यकता होगी। FAT32 को NTFS के कई वेरिएंट में से किसी के भी समझने में सरल होने की संभावना है। उदाहरण के लिए FAT32 फाइलसिस्टम को समझना देखें ।

Comments

@ Google से वंचित होने पर, मैं संभवतः लिनक्स को बूट करके शुरू करूंगा और ddकिसी दूसरी डिस्क पर किसी फाइल पर कच्ची फ्लैश फाइलसिस्टम को कॉपी करने के लिए उपयोग करूंगा, फिर एक हेक्स-व्यूअर का उपयोग करके इसे विशेष फाइल्स पर एक अच्छे संदर्भ-कार्य के साथ संयोजन में जांच सकता हूं (यदि स्वामित्व और अघोषित नहीं है)। मैं एक मेटाडेटा परिवर्तन कर सकता हूं touch, दोहरा सकता हूं ddऔर एक द्विआधारी अंतर का उपयोग कर सकता हूं ।

— RedGrittyBrick

अच्छी बात है कि मैं Google से वंचित नहीं हूं।

— कुलथु

@Cthulhu: पुराने लोगों को नेक्रोनोमिकॉन की कोई आवश्यकता नहीं है। fhtagn।

— RedGrittyBrick 15

सीधे हार्ड ड्राइव पर हेक्स-दर्शक का उपयोग करने के लिए ओएस को बदलने की कोई आवश्यकता नहीं है। बस एक सभ्य हेक्स दर्शक का उपयोग करें। (ऐसा लगता है कि यह भी hiewकर सकता है, लेकिन मुझे यकीन नहीं है क्योंकि मैं बहुत पहले खिड़कियों पर था)।

— रुस्लान

एचएक्सडी निश्चित रूप से इसे विंडोज पर करेगा। अतिरिक्त मेनू, डिस्क खोलें।

— Blorgbeard

Answer 3

मेटाडेटा को फ़ाइलों के रूप में संग्रहीत नहीं किया जाता है (न ही सामान्य फ़ाइल प्रबंधन उपकरण द्वारा रिपोर्ट किया गया है), यह डिस्क पर फाइल सिस्टम के डेटा पर संग्रहीत है।

फ़ाइल सिस्टम की प्रकृति / संस्करण के आधार पर, प्रत्येक प्रविष्टि मेटाडेटा जानकारी का प्रतिनिधित्व करने के लिए डिस्क स्थान की कुछ राशि लेगी।

इसके अलावा मास्टर फाइल टेबल में आवंटित स्थान के साथ, कुछ फाइल सिस्टम भी फाइल परिवर्तन (अतिरिक्त स्थान लेने) के बारे में पत्रिका रखेंगे, और कुछ फाइल सिस्टम को विशेष प्रयोजन मेटाडेटा वाले अतिरिक्त क्षेत्रों के साथ भी बढ़ाया जा सकता है।

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

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

Answer 4

मेटाडेटा फ़ाइल सिस्टम पर निर्भर करता है। आमतौर पर विनिमेय मीडिया पर उपयोग की जाने वाली सबसे बुनियादी फाइल सिस्टम एक डॉस फाइल सिस्टम (एफएटी) पर आधारित है। DOS में उपयोगकर्ता और अनुमतियां नहीं हैं। या, अधिक सही ढंग से, उस जानकारी में से कुछ को फ़ाइल नाम के 8 वें डेटा बिट में ले जाया जाता है। एकमात्र संसाधन ओवरहेड जो एक बुनियादी डॉस एफएस में उपयोग किया जाता है, वह फ़ाइल के ब्लॉक, या निर्देशिका के लिए है, जो कि इसमें है - और यह ब्लॉक संभवतः "पहले", पहले से ही निपटने के लिए प्रतिबद्ध है। IOW, एक खाली फ़ाइल जोड़ने से भंडारण का एक और हिस्सा नहीं जोड़ा जाएगा, लेकिन यह कुछ मौजूदा खपत और आवंटित बिट्स को बदल देगा ।

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

तो, एफएस प्रकार की जांच करें। यदि यह FAT है, तो संभवतः आपके पास मीडिया पर मेटाडेटा में दर्ज उपयोगकर्ता नहीं है। इसलिए - कोई स्थान उपयोग नहीं किया। :)

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

Answer 5

जैसा कि आप ऊपर की अंतिम तस्वीर में देखते हैं, एकमात्र स्थान जो फ़ाइल फ़्लैश पर कब्जा कर लेता है, वह अपनी सामग्री [वर्ण] के लिए स्थान है। तो मेटाडाटा फ़ाइल कहाँ है?

"मेटाडेटा फ़ाइल" वह निर्देशिका है जिसमें फ़ाइल शामिल है। यह मूल रूप से एक निर्देशिका क्या है - निर्देशिका की सामग्री का वर्णन मेटाडेटा का एक संग्रह।

मेरा मतलब है, जब मैं फ़ाइल को दूसरे कंप्यूटर पर ले जाता हूं, तो यह फ़ाइल का नाम, फ़ाइल का मालिक, दिनांक और संशोधित और कैसे समझ सकता है ...?

क्या यह किसी भी आकार पर कब्जा नहीं करता है? !!

हां, डायरेक्टरी में। अधिकांश फाइलशीट्स में, एक ही फाइल के दो अलग-अलग नाम हो सकते हैं यदि इसे दो अलग-अलग निर्देशिकाओं में जोड़ा जाता है।

क्या मैं फ़्लैश मेमोरी में मेटाडेटा फ़ाइल देख सकता हूँ?

यदि आपका फ़ाइल सिस्टम इसका समर्थन करता है, तो आप इसे निर्देशिका के आकार को देखकर देख सकते हैं।

Answer 6

मेटाडेटा कहाँ रखे जाते हैं?

जब हम मेटाडेटा के बारे में बात करते हैं, तो मेटाडेटा दो प्रकार के होते हैं।

पहले प्रकार में बनाई गई तिथि, अंतिम संशोधित तिथि, अंतिम अभिगमन तिथि शामिल है। फ़ाइल सिस्टम (यानी NTFS / FAT / Ext3 आदि ...) पर निर्भर करते हुए, अलग-अलग "मेटाडेटा" उपलब्ध होगा, उदाहरण के लिए विंडोज मालिक और NTFS पर अनुमति।

पहला प्रकार सभी फ़ाइलों पर लागू होता है, उदाहरण के लिए .txt फ़ाइल आपके उदाहरण में।

सभी फ़ाइल सिस्टम मास्टर फ़ाइल टेबल (NTFS के लिए MFT, अन्य फ़ाइल सिस्टम के कुछ अन्य नाम) में इन मेटाडेटा को शामिल करने के लिए रिक्त स्थान पूर्व-आवंटित करते हैं, जो उपयोगकर्ताओं द्वारा सीधे सुलभ नहीं है। चूंकि एमएफटी को ड्राइव क्षमता के हिस्से के रूप में नहीं गिना जाता है, इसलिए वैसे भी "अतिरिक्त" भंडारण स्थान की आवश्यकता नहीं है।

"मेटाडेटा" का दूसरा प्रकार फ़ाइल प्रकार या एप्लिकेशन द्वारा परिभाषित किया गया है। उदाहरण के लिए, कार्यालय दस्तावेज़ "लेखक", "विषय" और अन्य मेटाडेटा रखता है; जेपीईजी छवियां EXIF ​​डेटा का एक सेट रखती हैं जिसमें "तिथि चित्र", "कैमरा मॉडल", "शटर स्पीड" शामिल है; जबकि एमपी 3 साउंड में "एल्बम", "ट्रैक #", "बिटरेट" शामिल हैं ...

दूसरा प्रकार डीईईएस अतिरिक्त स्थान लेता है, क्योंकि ये "मेटाडेटा" फ़ाइल का हिस्सा हैं।

---

अलग-अलग ड्राइव में अलग-अलग आकार

जब आपकी टेक्स्ट फाइल चालू होती है तो C:\यह 4K तक ले जाती है। जब आप इसे अपने फ्लैश ड्राइव पर रखते हैं तो यह आकार में 1K हो जाता है H:\। ऐसा इसलिए है क्योंकि अलग-अलग विभाजनों के लिए अलग "ब्लॉक आकार" है।

फ़ाइलों को ब्लॉक में आवंटित स्थान हैं। इसलिए, ब्लॉक आकार 4K की एक फ़ाइल सिस्टम पर, 1 बाइट को 4K आवंटित किया जाता है, जबकि 4,097 बाइट्स (4K + 1 बाइट) को 8K आवंटित किया जाता है।

जाहिरा तौर पर आपके C:4K आकार के H:साथ स्वरूपित है, जबकि 1K ब्लॉक आकार के साथ स्वरूपित है, जिसके परिणामस्वरूप अंतर है।

Comments

जब मैं एक खाली पाठ फ़ाइल को फ्लैश मेमोरी में कॉपी करता हूं, तो उसका मेटाडेटा भी फ्लैश मेमोरी में चला जाएगा। अब, क्या कोई रास्ता है, उदाहरण के लिए लिनक्स में, मेटाडेटा फ़ाइल को देखने के लिए? उदाहरण के लिए बाइनरी में।

— TheGoodUser

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

— केनेथ एल