पदानुक्रमित फ़ाइल सिस्टम (Apple): Difference between revisions
(Created page with "{{short description|Proprietary file system by Apple}} {{About|the Apple file system used prior to Mac OS X 10.6|the general concept|Hierarchical file system|the IBM file syst...") |
No edit summary |
||
Line 2: | Line 2: | ||
{{About|the Apple file system used prior to Mac OS X 10.6|the general concept|Hierarchical file system|the IBM file system with the same name|Hierarchical File System (IBM MVS)}} | {{About|the Apple file system used prior to Mac OS X 10.6|the general concept|Hierarchical file system|the IBM file system with the same name|Hierarchical File System (IBM MVS)}} | ||
{{Distinguish|Filesystem Hierarchy Standard}} | {{Distinguish|Filesystem Hierarchy Standard}} | ||
{{Infobox filesystem | {{Infobox filesystem | ||
| name = HFS | | name = HFS | ||
Line 30: | Line 29: | ||
| OS = [[Classic Mac OS]], [[macOS]], [[GS/OS]], [[Linux]], [[Microsoft Windows]] (through MacDrive or [[Boot Camp (software)|Boot Camp]][[Installable File System|IFS]] drivers){{Citation needed|date=December 2010}} | | OS = [[Classic Mac OS]], [[macOS]], [[GS/OS]], [[Linux]], [[Microsoft Windows]] (through MacDrive or [[Boot Camp (software)|Boot Camp]][[Installable File System|IFS]] drivers){{Citation needed|date=December 2010}} | ||
}} | }} | ||
पदानुक्रमित [[फाइल सिस्टम]] (एचएफएस) [[क्लासिक मैक ओएस]] चलाने वाले कंप्यूटर सिस्टम में उपयोग के लिए ऐप्पल इंक द्वारा विकसित | पदानुक्रमित [[फाइल सिस्टम]] (एचएफएस) [[क्लासिक मैक ओएस]] चलाने वाले कंप्यूटर सिस्टम में उपयोग के लिए ऐप्पल इंक द्वारा विकसित [[मालिकाना सॉफ्टवेयर]] फ़ाइल सिस्टम है। मूल रूप से [[फ्लॉपी डिस्क]] और [[हार्ड डिस्क]] पर उपयोग के लिए डिज़ाइन किया गया, इसे [[ सीडी रॉम ]] जैसे रीड-ओनली मीडिया पर भी पाया जा सकता है। एचएफएस को मैक ओएस स्टैंडर्ड (या एचएफएस स्टैंडर्ड) भी कहा जाता है, जबकि इसके उत्तराधिकारी, [[एचएफएस प्लस]] को मैक ओएस एक्सटेंडेड (या एचएफएस एक्सटेंडेड) भी कहा जाता है। | ||
Mac OS<ref>{{cite web|url=http://www.computerworld.com/article/2467506/mac-os-x/losing-legacy-data-to-snow-leopard.html|title=स्नो लेपर्ड के कारण विरासती डेटा खोना|last=Gagne|first=Ken|date=2009-08-31|publisher=Computerworld|access-date=2009-09-07}}</ref> MacOS 10.15 से प्रारंभ होकर, HFS डिस्क को अब पढ़ा नहीं जा सकता है। | Mac OS<ref>{{cite web|url=http://www.computerworld.com/article/2467506/mac-os-x/losing-legacy-data-to-snow-leopard.html|title=स्नो लेपर्ड के कारण विरासती डेटा खोना|last=Gagne|first=Ken|date=2009-08-31|publisher=Computerworld|access-date=2009-09-07}}</ref> MacOS 10.15 से प्रारंभ होकर, HFS डिस्क को अब पढ़ा नहीं जा सकता है। | ||
== इतिहास == | == इतिहास == | ||
Apple ने सितंबर 1985 में HFS [[की]] शुरुआत की, विशेष रूप से [[मैकिंटोश 128K]] लिए Apple की पहली [[हार्ड डिस्क 20]] का समर्थन करने के लिए, [[मैकिंटोश फ़ाइल सिस्टम]] (MFS) की जगह, मूल फ़ाइल सिस्टम जिसे डेढ़ साल पहले पहले Macintush 128K कंप्यूटर के साथ पेश किया गया था। HFS ने असफल [[Apple III]] के लिए [[पदानुक्रमित फ़ाइल सिस्टम]], [[Apple SOS]] के साथ Apple के पहले ऑपरेटिंग सिस्टम पर भारी प्रभाव डाला, जो [[Apple IIe]] और Apple लिसा पर पदानुक्रमित फ़ाइल सिस्टम के लिए आधार के रूप में भी काम करता था। HFS को पैट्रिक डर्क्स और बिल ब्रुफ़ी द्वारा विकसित किया गया था। इसने एमएफएस के साथ कई डिज़ाइन सुविधाएँ साझा कीं जो उस समय की अन्य फ़ाइल प्रणालियों में उपलब्ध नहीं थीं (जैसे कि डॉस की फ़ाइल आवंटन तालिका)। फ़ाइलों में कई फ़ोर्क (सामान्यतः | Apple ने सितंबर 1985 में HFS [[की]] शुरुआत की, विशेष रूप से [[मैकिंटोश 128K]] लिए Apple की पहली [[हार्ड डिस्क 20]] का समर्थन करने के लिए, [[मैकिंटोश फ़ाइल सिस्टम]] (MFS) की जगह, मूल फ़ाइल सिस्टम जिसे डेढ़ साल पहले पहले Macintush 128K कंप्यूटर के साथ पेश किया गया था। HFS ने असफल [[Apple III]] के लिए [[पदानुक्रमित फ़ाइल सिस्टम]], [[Apple SOS]] के साथ Apple के पहले ऑपरेटिंग सिस्टम पर भारी प्रभाव डाला, जो [[Apple IIe]] और Apple लिसा पर पदानुक्रमित फ़ाइल सिस्टम के लिए आधार के रूप में भी काम करता था। HFS को पैट्रिक डर्क्स और बिल ब्रुफ़ी द्वारा विकसित किया गया था। इसने एमएफएस के साथ कई डिज़ाइन सुविधाएँ साझा कीं जो उस समय की अन्य फ़ाइल प्रणालियों में उपलब्ध नहीं थीं (जैसे कि डॉस की फ़ाइल आवंटन तालिका)। फ़ाइलों में कई फ़ोर्क (सामान्यतः डेटा और संसाधन फ़ोर्क) हो सकते हैं, जो फ़ाइल के मुख्य डेटा को उन संसाधनों से अलग संग्रहीत करने की अनुमति देता है जैसे कि आइकन जिन्हें स्थानीयकृत करने की आवश्यकता हो सकती है। फ़ाइलों को फ़ाइल नामों के बजाय अद्वितीय फ़ाइल आईडी के साथ संदर्भित किया गया था, और फ़ाइल नाम 31 वर्ण तक लंबे हो सकते हैं। | ||
हालाँकि, एमएफएस को बहुत छोटे और धीमे मीडिया, अर्थात् फ्लॉपी डिस्क पर उपयोग करने के लिए अनुकूलित किया गया था, इसलिए एचएफएस को बड़े मीडिया, विशेष रूप से [[हार्ड ड्राइव]] की शुरूआत के साथ आने वाली कुछ प्रदर्शन समस्याओं को दूर करने के लिए पेश किया गया था। मुख्य चिंता किसी फ़ोल्डर की सामग्री को प्रदर्शित करने में लगने वाले समय की थी। एमएफएस के तहत सभी फ़ाइल और निर्देशिका सूची की जानकारी एक ही फ़ाइल में संग्रहीत की गई थी, जिसे सिस्टम को किसी विशेष फ़ोल्डर में संग्रहीत फ़ाइलों की सूची बनाने के लिए खोजना था। इसने कुछ सौ किलोबाइट स्टोरेज और शायद सौ फाइलों वाले सिस्टम के साथ अच्छा काम किया, लेकिन जैसे-जैसे सिस्टम मेगाबाइट और हजारों फाइलों में बढ़ता गया, प्रदर्शन में तेजी से गिरावट आई। | हालाँकि, एमएफएस को बहुत छोटे और धीमे मीडिया, अर्थात् फ्लॉपी डिस्क पर उपयोग करने के लिए अनुकूलित किया गया था, इसलिए एचएफएस को बड़े मीडिया, विशेष रूप से [[हार्ड ड्राइव]] की शुरूआत के साथ आने वाली कुछ प्रदर्शन समस्याओं को दूर करने के लिए पेश किया गया था। मुख्य चिंता किसी फ़ोल्डर की सामग्री को प्रदर्शित करने में लगने वाले समय की थी। एमएफएस के तहत सभी फ़ाइल और निर्देशिका सूची की जानकारी एक ही फ़ाइल में संग्रहीत की गई थी, जिसे सिस्टम को किसी विशेष फ़ोल्डर में संग्रहीत फ़ाइलों की सूची बनाने के लिए खोजना था। इसने कुछ सौ किलोबाइट स्टोरेज और शायद सौ फाइलों वाले सिस्टम के साथ अच्छा काम किया, लेकिन जैसे-जैसे सिस्टम मेगाबाइट और हजारों फाइलों में बढ़ता गया, प्रदर्शन में तेजी से गिरावट आई। | ||
समाधान यह था कि एमएफएस की निर्देशिका संरचना को बड़े फ़ाइल सिस्टम के लिए उपयुक्त | समाधान यह था कि एमएफएस की निर्देशिका संरचना को बड़े फ़ाइल सिस्टम के लिए उपयुक्त से बदल दिया जाए। एचएफएस ने फ्लैट टेबल संरचना को कैटलॉग फ़ाइल से बदल दिया जो [[ बी-वृक्ष ]] संरचना का उपयोग करती है जिसे आकार की परवाह किए बिना बहुत तेज़ी से खोजा जा सकता है।<ref name="primer">{{Cite web |date=2003-05-25 |title=एचएफएस प्राइमर|url=http://macjournals.com/~mwj/mwj_samples/MWJ_20030525.pdf |url-status=dead |archive-url=https://web.archive.org/web/20191231011637/http://macjournals.com/%7Emwj/mwj_samples/MWJ_20030525.pdf |archive-date=2019-12-31 |website=MWJ |publisher=GCSF, Incorporated}}</ref> एचएफएस ने बड़ी संख्याएं रखने में सक्षम होने के लिए विभिन्न संरचनाओं को फिर से डिजाइन किया, 16-बिट पूर्णांक को लगभग सार्वभौमिक रूप से 32-बिट द्वारा प्रतिस्थापित किया गया। अजीब बात है, उन कुछ स्थानों में से एक जहां यह अपसाइज़िंग नहीं हुई थी वह फ़ाइल निर्देशिका ही थी, जो एचएफएस को प्रत्येक लॉजिकल डिस्क पर कुल 65,535 फ़ाइलों तक सीमित करती है। | ||
जबकि एचएफएस | जबकि एचएफएस मालिकाना फ़ाइल सिस्टम प्रारूप है, यह अच्छी तरह से प्रलेखित है; अधिकांश आधुनिक [[ऑपरेटिंग सिस्टम]] से एचएफएस-स्वरूपित डिस्क तक पहुंचने के लिए आमतौर पर समाधान उपलब्ध हैं। | ||
ऐप्पल ने आवश्यकतानुसार सितंबर 1985 में मैकिंटोश के लिए अपनी पहली 20 एमबी हार्ड डिस्क 20 की पेशकश के साथ एचएफएस की शुरुआत की, जहां इसे | ऐप्पल ने आवश्यकतानुसार सितंबर 1985 में मैकिंटोश के लिए अपनी पहली 20 एमबी हार्ड डिस्क 20 की पेशकश के साथ एचएफएस की शुरुआत की, जहां इसे पैच फ़ाइल (हार्ड डिस्क 20) का उपयोग करके बूट पर एमएफएस फ्लॉपी डिस्क से रैम में लोड किया गया था। हालाँकि, HFS को तब तक व्यापक रूप से पेश नहीं किया गया था जब तक कि इसे 128K [[ केवल पढ़ने के लिये मेमोरी ]] में शामिल नहीं किया गया था, जो जनवरी 1986 में [[मैकिंटोश प्लस]] के साथ मैकिंटोश के लिए बड़े 800 KB फ़्लॉपी डिस्क ड्राइव के साथ शुरू हुआ था जिसमें HFS का भी उपयोग किया गया था। एचएफएस की शुरूआत ऐप्पल द्वारा मैकिंटोश कंप्यूटर मॉडल को पीछे छोड़ने वाली पहली प्रगति थी: मूल मैकिंटोश 128K, जिसमें एचएफएस कोड को लोड करने के लिए पर्याप्त मेमोरी की कमी थी और इसे तुरंत बंद कर दिया गया था। | ||
1998 में, Apple ने HFS में डिस्क स्थान के अकुशल आवंटन को संबोधित करने और अन्य सुधार जोड़ने के लिए HFS प्लस की शुरुआत की। HFS प्लस अभी भी Mac OS के वर्तमान संस्करणों द्वारा समर्थित है, लेकिन Mac OS या अद्यतन किया गया। MacOS Sierra (10.12) में, Apple के रिलीज़ नोट्स में कहा गया है कि HFS मानक फ़ाइल सिस्टम अब समर्थित नहीं है।<ref>{{cite web|title=What's New in macOS: macOS Sierra 10.12|url=https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html#//apple_ref/doc/uid/TP40017145-SW1|publisher=Apple|access-date=25 January 2017}}</ref> हालाँकि, रीड-ओनली HFS मानक समर्थन macOS 10.15 के रिलीज़ होने तक काम करता रहा।<ref>{{cite web|title= MacOS कैटालिना और बाद के संस्करण पर HFS क्लासिक ड्राइव कैसे माउंट करें|date=25 July 2020 |url=https://www.matthewhughes.co.uk/how-to-mount-hfs-classic-drives-on-macos-catalina-and-later/|publisher=Matthew Hughes|access-date=2 March 2022}}</ref> 35 वर्षों के बाद क्लासिक एचएफएस मानक के लिए आधिकारिक समर्थन समाप्त करना।<ref>{{Cite web |date=2022-06-21 |title=About the security content of Security Update 2021-005 Mojave |url=https://support.apple.com/en-us/HT212603 |access-date=2023-05-18 |website=Apple Support |language=en}}</ref> | 1998 में, Apple ने HFS में डिस्क स्थान के अकुशल आवंटन को संबोधित करने और अन्य सुधार जोड़ने के लिए HFS प्लस की शुरुआत की। HFS प्लस अभी भी Mac OS के वर्तमान संस्करणों द्वारा समर्थित है, लेकिन Mac OS या अद्यतन किया गया। MacOS Sierra (10.12) में, Apple के रिलीज़ नोट्स में कहा गया है कि HFS मानक फ़ाइल सिस्टम अब समर्थित नहीं है।<ref>{{cite web|title=What's New in macOS: macOS Sierra 10.12|url=https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html#//apple_ref/doc/uid/TP40017145-SW1|publisher=Apple|access-date=25 January 2017}}</ref> हालाँकि, रीड-ओनली HFS मानक समर्थन macOS 10.15 के रिलीज़ होने तक काम करता रहा।<ref>{{cite web|title= MacOS कैटालिना और बाद के संस्करण पर HFS क्लासिक ड्राइव कैसे माउंट करें|date=25 July 2020 |url=https://www.matthewhughes.co.uk/how-to-mount-hfs-classic-drives-on-macos-catalina-and-later/|publisher=Matthew Hughes|access-date=2 March 2022}}</ref> 35 वर्षों के बाद क्लासिक एचएफएस मानक के लिए आधिकारिक समर्थन समाप्त करना।<ref>{{Cite web |date=2022-06-21 |title=About the security content of Security Update 2021-005 Mojave |url=https://support.apple.com/en-us/HT212603 |access-date=2023-05-18 |website=Apple Support |language=en}}</ref> | ||
==डिज़ाइन== | ==डिज़ाइन== | ||
एक भंडारण मात्रा स्वाभाविक रूप से 512 बाइट्स के तार्किक ब्लॉक में विभाजित है। पदानुक्रमित फ़ाइल सिस्टम इन तार्किक ब्लॉकों को आवंटन ब्लॉकों में समूहित करता है, जिसमें वॉल्यूम के कुल आकार के आधार पर एक या अधिक तार्किक ब्लॉक हो सकते हैं। एचएफएस आवंटन ब्लॉकों को संबोधित करने के लिए 16-बिट मान का उपयोग करता है, जिससे आवंटन ब्लॉकों की संख्या 65,535 (2) तक सीमित हो जाती है<sup>16</sup>-1). | एक भंडारण मात्रा स्वाभाविक रूप से 512 बाइट्स के तार्किक ब्लॉक में विभाजित है। पदानुक्रमित फ़ाइल सिस्टम इन तार्किक ब्लॉकों को आवंटन ब्लॉकों में समूहित करता है, जिसमें वॉल्यूम के कुल आकार के आधार पर एक या अधिक तार्किक ब्लॉक हो सकते हैं। एचएफएस आवंटन ब्लॉकों को संबोधित करने के लिए 16-बिट मान का उपयोग करता है, जिससे आवंटन ब्लॉकों की संख्या 65,535 (2) तक सीमित हो जाती है<sup>16</sup>-1). | ||
पांच संरचनाएं | पांच संरचनाएं एचएफएस वॉल्यूम बनाती हैं: | ||
# वॉल्यूम के लॉजिकल ब्लॉक 0 और 1 [[ बूट क्षेत्र ]] हैं, जिनमें सिस्टम स्टार्टअप जानकारी होती है।<ref name="primer" />उदाहरण के लिए, सिस्टम और शेल (आमतौर पर [[ मैकिंटोश खोजक ]]) फ़ाइलों के नाम जो स्टार्टअप पर लोड किए जाते हैं। | # वॉल्यूम के लॉजिकल ब्लॉक 0 और 1 [[ बूट क्षेत्र ]] हैं, जिनमें सिस्टम स्टार्टअप जानकारी होती है।<ref name="primer" />उदाहरण के लिए, सिस्टम और शेल (आमतौर पर [[ मैकिंटोश खोजक ]]) फ़ाइलों के नाम जो स्टार्टअप पर लोड किए जाते हैं। | ||
# लॉजिकल ब्लॉक 2 में मास्टर डायरेक्ट्री ब्लॉक (जिसे एमडीबी भी कहा जाता है) शामिल है। यह वॉल्यूम के बारे में डेटा की | # लॉजिकल ब्लॉक 2 में मास्टर डायरेक्ट्री ब्लॉक (जिसे एमडीबी भी कहा जाता है) शामिल है। यह वॉल्यूम के बारे में डेटा की विस्तृत विविधता को परिभाषित करता है, उदाहरण के लिए जब वॉल्यूम बनाया गया था तो दिनांक और समय टिकटें, अन्य वॉल्यूम संरचनाओं का स्थान जैसे वॉल्यूम बिटमैप या आवंटन ब्लॉक जैसी तार्किक संरचनाओं का आकार। एमडीबी का डुप्लिकेट भी है जिसे वैकल्पिक मास्टर निर्देशिका ब्लॉक (जिसे वैकल्पिक एमडीबी भी कहा जाता है) दूसरे से अंतिम तार्किक ब्लॉक में वॉल्यूम के विपरीत छोर पर स्थित है। यह मुख्य रूप से डिस्क उपयोगिताओं द्वारा उपयोग के लिए है और इसे केवल तभी अपडेट किया जाता है जब कैटलॉग फ़ाइल या एक्सटेंशन ओवरफ़्लो फ़ाइल का आकार बढ़ता है। | ||
# लॉजिकल ब्लॉक 3 वॉल्यूम बिटमैप का शुरुआती ब्लॉक है, जो ट्रैक करता है कि कौन से आवंटन ब्लॉक उपयोग में हैं और कौन से निःशुल्क हैं। वॉल्यूम पर प्रत्येक आवंटन ब्लॉक को मानचित्र में | # लॉजिकल ब्लॉक 3 वॉल्यूम बिटमैप का शुरुआती ब्लॉक है, जो ट्रैक करता है कि कौन से आवंटन ब्लॉक उपयोग में हैं और कौन से निःशुल्क हैं। वॉल्यूम पर प्रत्येक आवंटन ब्लॉक को मानचित्र में बिट द्वारा दर्शाया गया है: यदि बिट सेट है तो ब्लॉक उपयोग में है; यदि यह स्पष्ट है तो ब्लॉक का उपयोग निःशुल्क है। चूंकि वॉल्यूम बिटमैप में प्रत्येक आवंटन ब्लॉक का प्रतिनिधित्व करने के लिए बिट होना चाहिए, इसका आकार वॉल्यूम के आकार से ही निर्धारित होता है।<ref name="primer" /># एक्स्टेंट ओवरफ़्लो फ़ाइल बी-ट्री है जिसमें अतिरिक्त एक्सटेंशन होते हैं जो रिकॉर्ड करते हैं कि कैटलॉग फ़ाइल में शुरुआती तीन एक्सटेंशन का उपयोग होने पर कौन से आवंटन ब्लॉक किन फ़ाइलों को आवंटित किए जाते हैं। बाद के संस्करणों में एक्सटेंट ओवरफ़्लो फ़ाइल में खराब ब्लॉकों को रिकॉर्ड करने [[फ़ाइल सीमा]] को संग्रहीत करने की क्षमता भी जोड़ी गई, ताकि फ़ाइल सिस्टम को किसी फ़ाइल में खराब ब्लॉक को आवंटित करने की कोशिश करने से रोका जा सके। | ||
# कैटलॉग फ़ाइल | # कैटलॉग फ़ाइल अन्य बी-ट्री है जिसमें वॉल्यूम में संग्रहीत सभी फ़ाइलों और निर्देशिकाओं के रिकॉर्ड शामिल हैं। यह चार प्रकार के रिकॉर्ड संग्रहीत करता है। प्रत्येक फ़ाइल में फ़ाइल थ्रेड रिकॉर्ड और फ़ाइल रिकॉर्ड होता है जबकि प्रत्येक निर्देशिका में निर्देशिका थ्रेड रिकॉर्ड और निर्देशिका रिकॉर्ड होता है। कैटलॉग फ़ाइल में फ़ाइलें और निर्देशिकाएं उनके अद्वितीय कैटलॉग नोड आईडी (या CNID) द्वारा स्थित होती हैं। | ||
#* एक फ़ाइल थ्रेड रिकॉर्ड केवल फ़ाइल का नाम और उसकी मूल निर्देशिका का CNID संग्रहीत करता है। | #* एक फ़ाइल थ्रेड रिकॉर्ड केवल फ़ाइल का नाम और उसकी मूल निर्देशिका का CNID संग्रहीत करता है। | ||
#* एक फ़ाइल रिकॉर्ड फ़ाइल के बारे में विभिन्न प्रकार के मेटाडेटा को संग्रहीत करता है जिसमें उसका CNID, फ़ाइल का आकार, तीन टाइमस्टैम्प (जब फ़ाइल बनाई गई थी, अंतिम बार संशोधित, अंतिम बार बैकअप किया गया), डेटा की पहली फ़ाइल विस्तार और संसाधन फोर्क्स शामिल हैं और एक्सटेंट ओवरफ़्लो फ़ाइल में फ़ाइल के पहले डेटा और संसाधन सीमा रिकॉर्ड के संकेतक। फ़ाइल रिकॉर्ड दो 16 बाइट फ़ील्ड भी संग्रहीत करता है जिनका उपयोग फ़ाइंडर द्वारा फ़ाइल के बारे में विशेषताओं को संग्रहीत करने के लिए किया जाता है, जिसमें इसके [[निर्माता कोड]], प्रकार कोड, फ़ाइल को प्रदर्शित होने वाली विंडो और विंडो के भीतर उसके स्थान जैसी चीज़ें शामिल हैं। | #* एक फ़ाइल रिकॉर्ड फ़ाइल के बारे में विभिन्न प्रकार के मेटाडेटा को संग्रहीत करता है जिसमें उसका CNID, फ़ाइल का आकार, तीन टाइमस्टैम्प (जब फ़ाइल बनाई गई थी, अंतिम बार संशोधित, अंतिम बार बैकअप किया गया), डेटा की पहली फ़ाइल विस्तार और संसाधन फोर्क्स शामिल हैं और एक्सटेंट ओवरफ़्लो फ़ाइल में फ़ाइल के पहले डेटा और संसाधन सीमा रिकॉर्ड के संकेतक। फ़ाइल रिकॉर्ड दो 16 बाइट फ़ील्ड भी संग्रहीत करता है जिनका उपयोग फ़ाइंडर द्वारा फ़ाइल के बारे में विशेषताओं को संग्रहीत करने के लिए किया जाता है, जिसमें इसके [[निर्माता कोड]], प्रकार कोड, फ़ाइल को प्रदर्शित होने वाली विंडो और विंडो के भीतर उसके स्थान जैसी चीज़ें शामिल हैं। | ||
Line 62: | Line 59: | ||
== सीमाएँ == | == सीमाएँ == | ||
कैटलॉग फ़ाइल, जो सभी फ़ाइल और निर्देशिका रिकॉर्ड को एक ही डेटा संरचना में संग्रहीत करती है, जब सिस्टम कंप्यूटर [[कंप्यूटर मल्टीटास्किंग]] की अनुमति देता है, तो प्रदर्शन संबंधी समस्याएं उत्पन्न होती हैं, क्योंकि एक समय में केवल एक ही प्रोग्राम इस संरचना में लिख सकता है, जिसका अर्थ है कि कई प्रोग्राम प्रतीक्षा कर सकते हैं। | कैटलॉग फ़ाइल, जो सभी फ़ाइल और निर्देशिका रिकॉर्ड को एक ही डेटा संरचना में संग्रहीत करती है, जब सिस्टम कंप्यूटर [[कंप्यूटर मल्टीटास्किंग]] की अनुमति देता है, तो प्रदर्शन संबंधी समस्याएं उत्पन्न होती हैं, क्योंकि एक समय में केवल एक ही प्रोग्राम इस संरचना में लिख सकता है, जिसका अर्थ है कि कई प्रोग्राम प्रतीक्षा कर सकते हैं। प्रोग्राम द्वारा सिस्टम को बाधित करने के कारण कतार।<ref>{{cite book | last=Giampaolo | first=Dominic | author-link=Dominic Giampaolo | year=1999 | url=http://www.nobius.org/~dbg/practical-file-system-design.pdf | title=Be फ़ाइल सिस्टम के साथ प्रैक्टिकल फ़ाइल सिस्टम डिज़ाइन| publisher=Morgan Kaufmann | isbn=1-55860-497-9 | pages=37 | access-date=2006-07-13 | archive-url=https://web.archive.org/web/20170213221835/http://www.nobius.org/~dbg/practical-file-system-design.pdf | archive-date=2017-02-13 | url-status=dead }}</ref> यह गंभीर विश्वसनीयता चिंता का विषय भी है, क्योंकि इस फ़ाइल के क्षतिग्रस्त होने से संपूर्ण फ़ाइल सिस्टम नष्ट हो सकता है। यह अन्य फ़ाइल सिस्टमों से भिन्न है जो फ़ाइल और निर्देशिका रिकॉर्ड को अलग-अलग संरचनाओं (जैसे DOS की FAT फ़ाइल सिस्टम या [[यूनिक्स फ़ाइल सिस्टम]]) में संग्रहीत करते हैं, जहाँ संरचना को डिस्क पर वितरित करने का मतलब है कि एकल निर्देशिका को नुकसान पहुँचाना आम तौर पर गैर-घातक है और डेटा संभवतः गैर-क्षतिग्रस्त भागों में रखे गए डेटा के साथ इसका पुनर्निर्माण किया जा सकता है। | ||
इसके अतिरिक्त, 65,535 आवंटन ब्लॉकों की सीमा के परिणामस्वरूप फ़ाइलों का न्यूनतम आकार डिस्क के आकार 1/65,535वें के बराबर हो गया। इस प्रकार, कोई भी वॉल्यूम, चाहे उसका आकार कोई भी हो, अधिकतम 65,535 फ़ाइलें ही संग्रहीत कर सकता है। इसके अलावा, किसी भी फ़ाइल को आवंटन ब्लॉक आकार तक, वास्तव में आवश्यकता से अधिक स्थान आवंटित किया जाएगा। जब डिस्क छोटी थीं, तो इसका कोई परिणाम नहीं था, क्योंकि व्यक्तिगत आवंटन ब्लॉक का आकार तुच्छ था, लेकिन जैसे-जैसे डिस्क 1 जीबी के निशान तक पहुंचने लगी, किसी भी फ़ाइल द्वारा कब्जा की जा सकने वाली सबसे छोटी जगह (एक एकल आवंटन ब्लॉक) अत्यधिक बड़ी हो गई , डिस्क स्थान की महत्वपूर्ण मात्रा बर्बाद कर रहा है। उदाहरण के लिए, 1 जीबी डिस्क पर, एचएफएस के तहत आवंटन ब्लॉक का आकार 16 केबी है, इसलिए 1 बाइट फ़ाइल भी 16 केबी डिस्क स्थान लेगी। बड़ी फ़ाइलें (जैसे चित्र, डेटाबेस या ऑडियो) रखने वाले उपयोगकर्ताओं के लिए यह स्थिति कम समस्या वाली थी क्योंकि ये बड़ी फ़ाइलें अपने फ़ाइल आकार के प्रतिशत के रूप में कम स्थान बर्बाद करती थीं। दूसरी ओर, कई छोटी फ़ाइलों वाले उपयोगकर्ता, बड़े आवंटन ब्लॉक आकार के कारण प्रचुर मात्रा में स्थान खो सकते हैं। इसने मैक उपयोगकर्ताओं के लिए छोटे लॉजिकल वॉल्यूम में विभाजन डिस्क को बहुत आकर्षक बना दिया, क्योंकि छोटे वॉल्यूम पर संग्रहीत छोटे दस्तावेज़ बड़े विभाजन पर रहने की तुलना में बहुत कम जगह लेंगे। यही समस्या FAT16 फ़ाइल सिस्टम में भी मौजूद थी। | इसके अतिरिक्त, 65,535 आवंटन ब्लॉकों की सीमा के परिणामस्वरूप फ़ाइलों का न्यूनतम आकार डिस्क के आकार 1/65,535वें के बराबर हो गया। इस प्रकार, कोई भी वॉल्यूम, चाहे उसका आकार कोई भी हो, अधिकतम 65,535 फ़ाइलें ही संग्रहीत कर सकता है। इसके अलावा, किसी भी फ़ाइल को आवंटन ब्लॉक आकार तक, वास्तव में आवश्यकता से अधिक स्थान आवंटित किया जाएगा। जब डिस्क छोटी थीं, तो इसका कोई परिणाम नहीं था, क्योंकि व्यक्तिगत आवंटन ब्लॉक का आकार तुच्छ था, लेकिन जैसे-जैसे डिस्क 1 जीबी के निशान तक पहुंचने लगी, किसी भी फ़ाइल द्वारा कब्जा की जा सकने वाली सबसे छोटी जगह (एक एकल आवंटन ब्लॉक) अत्यधिक बड़ी हो गई , डिस्क स्थान की महत्वपूर्ण मात्रा बर्बाद कर रहा है। उदाहरण के लिए, 1 जीबी डिस्क पर, एचएफएस के तहत आवंटन ब्लॉक का आकार 16 केबी है, इसलिए 1 बाइट फ़ाइल भी 16 केबी डिस्क स्थान लेगी। बड़ी फ़ाइलें (जैसे चित्र, डेटाबेस या ऑडियो) रखने वाले उपयोगकर्ताओं के लिए यह स्थिति कम समस्या वाली थी क्योंकि ये बड़ी फ़ाइलें अपने फ़ाइल आकार के प्रतिशत के रूप में कम स्थान बर्बाद करती थीं। दूसरी ओर, कई छोटी फ़ाइलों वाले उपयोगकर्ता, बड़े आवंटन ब्लॉक आकार के कारण प्रचुर मात्रा में स्थान खो सकते हैं। इसने मैक उपयोगकर्ताओं के लिए छोटे लॉजिकल वॉल्यूम में विभाजन डिस्क को बहुत आकर्षक बना दिया, क्योंकि छोटे वॉल्यूम पर संग्रहीत छोटे दस्तावेज़ बड़े विभाजन पर रहने की तुलना में बहुत कम जगह लेंगे। यही समस्या FAT16 फ़ाइल सिस्टम में भी मौजूद थी। | ||
Line 75: | Line 72: | ||
==संदर्भ== | ==संदर्भ== | ||
{{reflist}} | {{reflist}} | ||
== बाहरी संबंध == | == बाहरी संबंध == | ||
* [https://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-99.html HFS specification] from developer.apple.com | * [https://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-99.html HFS specification] from developer.apple.com |
Revision as of 20:18, 16 July 2023
Developer(s) | Apple Computer |
---|---|
Full name | Hierarchical File System |
Introduced | September 17, 1985System 2.1 | with
Partition identifier | Apple_HFS (Apple Partition Map)0xAF (MBR) HFS and HFS+ |
Structures | |
Directory contents | B-tree |
File allocation | Bitmap |
Bad blocks | B-tree |
Limits | |
Max. volume size | 2 TB (2 × 10244 bytes) |
Max. file size | 2 GB (2 × 10243 bytes) |
Max. number of files | 65535 |
Max. filename length | 31 characters |
Allowed characters in filenames | All 8-bit values except :. Discouraged null and non-printing characters. |
Features | |
Dates recorded | Creation, modification, backup |
Date range | January 1, 1904 – February 6, 2040 |
Date resolution | 1s |
Forks | Only 2 (data and resource) |
Attributes | Color (3 bits, all other flags 1 bit), locked, custom icon, bundle, invisible, alias, system, stationery, inited, no INIT resources, shared, desktop |
File system permissions | AppleShare |
Transparent compression | Yes (third-party); Stacker, AutoDoubler, TimesTwo, Now Compress, StuffIt SpaceSaver, Alysis Software products (SuperDisk!, More Disk Space, The Alysis Disk Expander and eDisk), AutoSqueeze |
Transparent encryption | No |
Other | |
Supported operating systems | Classic Mac OS, macOS, GS/OS, Linux, Microsoft Windows (through MacDrive or Boot CampIFS drivers)[citation needed] |
पदानुक्रमित फाइल सिस्टम (एचएफएस) क्लासिक मैक ओएस चलाने वाले कंप्यूटर सिस्टम में उपयोग के लिए ऐप्पल इंक द्वारा विकसित मालिकाना सॉफ्टवेयर फ़ाइल सिस्टम है। मूल रूप से फ्लॉपी डिस्क और हार्ड डिस्क पर उपयोग के लिए डिज़ाइन किया गया, इसे सीडी रॉम जैसे रीड-ओनली मीडिया पर भी पाया जा सकता है। एचएफएस को मैक ओएस स्टैंडर्ड (या एचएफएस स्टैंडर्ड) भी कहा जाता है, जबकि इसके उत्तराधिकारी, एचएफएस प्लस को मैक ओएस एक्सटेंडेड (या एचएफएस एक्सटेंडेड) भी कहा जाता है।
Mac OS[1] MacOS 10.15 से प्रारंभ होकर, HFS डिस्क को अब पढ़ा नहीं जा सकता है।
इतिहास
Apple ने सितंबर 1985 में HFS की शुरुआत की, विशेष रूप से मैकिंटोश 128K लिए Apple की पहली हार्ड डिस्क 20 का समर्थन करने के लिए, मैकिंटोश फ़ाइल सिस्टम (MFS) की जगह, मूल फ़ाइल सिस्टम जिसे डेढ़ साल पहले पहले Macintush 128K कंप्यूटर के साथ पेश किया गया था। HFS ने असफल Apple III के लिए पदानुक्रमित फ़ाइल सिस्टम, Apple SOS के साथ Apple के पहले ऑपरेटिंग सिस्टम पर भारी प्रभाव डाला, जो Apple IIe और Apple लिसा पर पदानुक्रमित फ़ाइल सिस्टम के लिए आधार के रूप में भी काम करता था। HFS को पैट्रिक डर्क्स और बिल ब्रुफ़ी द्वारा विकसित किया गया था। इसने एमएफएस के साथ कई डिज़ाइन सुविधाएँ साझा कीं जो उस समय की अन्य फ़ाइल प्रणालियों में उपलब्ध नहीं थीं (जैसे कि डॉस की फ़ाइल आवंटन तालिका)। फ़ाइलों में कई फ़ोर्क (सामान्यतः डेटा और संसाधन फ़ोर्क) हो सकते हैं, जो फ़ाइल के मुख्य डेटा को उन संसाधनों से अलग संग्रहीत करने की अनुमति देता है जैसे कि आइकन जिन्हें स्थानीयकृत करने की आवश्यकता हो सकती है। फ़ाइलों को फ़ाइल नामों के बजाय अद्वितीय फ़ाइल आईडी के साथ संदर्भित किया गया था, और फ़ाइल नाम 31 वर्ण तक लंबे हो सकते हैं।
हालाँकि, एमएफएस को बहुत छोटे और धीमे मीडिया, अर्थात् फ्लॉपी डिस्क पर उपयोग करने के लिए अनुकूलित किया गया था, इसलिए एचएफएस को बड़े मीडिया, विशेष रूप से हार्ड ड्राइव की शुरूआत के साथ आने वाली कुछ प्रदर्शन समस्याओं को दूर करने के लिए पेश किया गया था। मुख्य चिंता किसी फ़ोल्डर की सामग्री को प्रदर्शित करने में लगने वाले समय की थी। एमएफएस के तहत सभी फ़ाइल और निर्देशिका सूची की जानकारी एक ही फ़ाइल में संग्रहीत की गई थी, जिसे सिस्टम को किसी विशेष फ़ोल्डर में संग्रहीत फ़ाइलों की सूची बनाने के लिए खोजना था। इसने कुछ सौ किलोबाइट स्टोरेज और शायद सौ फाइलों वाले सिस्टम के साथ अच्छा काम किया, लेकिन जैसे-जैसे सिस्टम मेगाबाइट और हजारों फाइलों में बढ़ता गया, प्रदर्शन में तेजी से गिरावट आई।
समाधान यह था कि एमएफएस की निर्देशिका संरचना को बड़े फ़ाइल सिस्टम के लिए उपयुक्त से बदल दिया जाए। एचएफएस ने फ्लैट टेबल संरचना को कैटलॉग फ़ाइल से बदल दिया जो बी-वृक्ष संरचना का उपयोग करती है जिसे आकार की परवाह किए बिना बहुत तेज़ी से खोजा जा सकता है।[2] एचएफएस ने बड़ी संख्याएं रखने में सक्षम होने के लिए विभिन्न संरचनाओं को फिर से डिजाइन किया, 16-बिट पूर्णांक को लगभग सार्वभौमिक रूप से 32-बिट द्वारा प्रतिस्थापित किया गया। अजीब बात है, उन कुछ स्थानों में से एक जहां यह अपसाइज़िंग नहीं हुई थी वह फ़ाइल निर्देशिका ही थी, जो एचएफएस को प्रत्येक लॉजिकल डिस्क पर कुल 65,535 फ़ाइलों तक सीमित करती है।
जबकि एचएफएस मालिकाना फ़ाइल सिस्टम प्रारूप है, यह अच्छी तरह से प्रलेखित है; अधिकांश आधुनिक ऑपरेटिंग सिस्टम से एचएफएस-स्वरूपित डिस्क तक पहुंचने के लिए आमतौर पर समाधान उपलब्ध हैं।
ऐप्पल ने आवश्यकतानुसार सितंबर 1985 में मैकिंटोश के लिए अपनी पहली 20 एमबी हार्ड डिस्क 20 की पेशकश के साथ एचएफएस की शुरुआत की, जहां इसे पैच फ़ाइल (हार्ड डिस्क 20) का उपयोग करके बूट पर एमएफएस फ्लॉपी डिस्क से रैम में लोड किया गया था। हालाँकि, HFS को तब तक व्यापक रूप से पेश नहीं किया गया था जब तक कि इसे 128K केवल पढ़ने के लिये मेमोरी में शामिल नहीं किया गया था, जो जनवरी 1986 में मैकिंटोश प्लस के साथ मैकिंटोश के लिए बड़े 800 KB फ़्लॉपी डिस्क ड्राइव के साथ शुरू हुआ था जिसमें HFS का भी उपयोग किया गया था। एचएफएस की शुरूआत ऐप्पल द्वारा मैकिंटोश कंप्यूटर मॉडल को पीछे छोड़ने वाली पहली प्रगति थी: मूल मैकिंटोश 128K, जिसमें एचएफएस कोड को लोड करने के लिए पर्याप्त मेमोरी की कमी थी और इसे तुरंत बंद कर दिया गया था।
1998 में, Apple ने HFS में डिस्क स्थान के अकुशल आवंटन को संबोधित करने और अन्य सुधार जोड़ने के लिए HFS प्लस की शुरुआत की। HFS प्लस अभी भी Mac OS के वर्तमान संस्करणों द्वारा समर्थित है, लेकिन Mac OS या अद्यतन किया गया। MacOS Sierra (10.12) में, Apple के रिलीज़ नोट्स में कहा गया है कि HFS मानक फ़ाइल सिस्टम अब समर्थित नहीं है।[3] हालाँकि, रीड-ओनली HFS मानक समर्थन macOS 10.15 के रिलीज़ होने तक काम करता रहा।[4] 35 वर्षों के बाद क्लासिक एचएफएस मानक के लिए आधिकारिक समर्थन समाप्त करना।[5]
डिज़ाइन
एक भंडारण मात्रा स्वाभाविक रूप से 512 बाइट्स के तार्किक ब्लॉक में विभाजित है। पदानुक्रमित फ़ाइल सिस्टम इन तार्किक ब्लॉकों को आवंटन ब्लॉकों में समूहित करता है, जिसमें वॉल्यूम के कुल आकार के आधार पर एक या अधिक तार्किक ब्लॉक हो सकते हैं। एचएफएस आवंटन ब्लॉकों को संबोधित करने के लिए 16-बिट मान का उपयोग करता है, जिससे आवंटन ब्लॉकों की संख्या 65,535 (2) तक सीमित हो जाती है16-1).
पांच संरचनाएं एचएफएस वॉल्यूम बनाती हैं:
- वॉल्यूम के लॉजिकल ब्लॉक 0 और 1 बूट क्षेत्र हैं, जिनमें सिस्टम स्टार्टअप जानकारी होती है।[2]उदाहरण के लिए, सिस्टम और शेल (आमतौर पर मैकिंटोश खोजक ) फ़ाइलों के नाम जो स्टार्टअप पर लोड किए जाते हैं।
- लॉजिकल ब्लॉक 2 में मास्टर डायरेक्ट्री ब्लॉक (जिसे एमडीबी भी कहा जाता है) शामिल है। यह वॉल्यूम के बारे में डेटा की विस्तृत विविधता को परिभाषित करता है, उदाहरण के लिए जब वॉल्यूम बनाया गया था तो दिनांक और समय टिकटें, अन्य वॉल्यूम संरचनाओं का स्थान जैसे वॉल्यूम बिटमैप या आवंटन ब्लॉक जैसी तार्किक संरचनाओं का आकार। एमडीबी का डुप्लिकेट भी है जिसे वैकल्पिक मास्टर निर्देशिका ब्लॉक (जिसे वैकल्पिक एमडीबी भी कहा जाता है) दूसरे से अंतिम तार्किक ब्लॉक में वॉल्यूम के विपरीत छोर पर स्थित है। यह मुख्य रूप से डिस्क उपयोगिताओं द्वारा उपयोग के लिए है और इसे केवल तभी अपडेट किया जाता है जब कैटलॉग फ़ाइल या एक्सटेंशन ओवरफ़्लो फ़ाइल का आकार बढ़ता है।
- लॉजिकल ब्लॉक 3 वॉल्यूम बिटमैप का शुरुआती ब्लॉक है, जो ट्रैक करता है कि कौन से आवंटन ब्लॉक उपयोग में हैं और कौन से निःशुल्क हैं। वॉल्यूम पर प्रत्येक आवंटन ब्लॉक को मानचित्र में बिट द्वारा दर्शाया गया है: यदि बिट सेट है तो ब्लॉक उपयोग में है; यदि यह स्पष्ट है तो ब्लॉक का उपयोग निःशुल्क है। चूंकि वॉल्यूम बिटमैप में प्रत्येक आवंटन ब्लॉक का प्रतिनिधित्व करने के लिए बिट होना चाहिए, इसका आकार वॉल्यूम के आकार से ही निर्धारित होता है।[2]# एक्स्टेंट ओवरफ़्लो फ़ाइल बी-ट्री है जिसमें अतिरिक्त एक्सटेंशन होते हैं जो रिकॉर्ड करते हैं कि कैटलॉग फ़ाइल में शुरुआती तीन एक्सटेंशन का उपयोग होने पर कौन से आवंटन ब्लॉक किन फ़ाइलों को आवंटित किए जाते हैं। बाद के संस्करणों में एक्सटेंट ओवरफ़्लो फ़ाइल में खराब ब्लॉकों को रिकॉर्ड करने फ़ाइल सीमा को संग्रहीत करने की क्षमता भी जोड़ी गई, ताकि फ़ाइल सिस्टम को किसी फ़ाइल में खराब ब्लॉक को आवंटित करने की कोशिश करने से रोका जा सके।
- कैटलॉग फ़ाइल अन्य बी-ट्री है जिसमें वॉल्यूम में संग्रहीत सभी फ़ाइलों और निर्देशिकाओं के रिकॉर्ड शामिल हैं। यह चार प्रकार के रिकॉर्ड संग्रहीत करता है। प्रत्येक फ़ाइल में फ़ाइल थ्रेड रिकॉर्ड और फ़ाइल रिकॉर्ड होता है जबकि प्रत्येक निर्देशिका में निर्देशिका थ्रेड रिकॉर्ड और निर्देशिका रिकॉर्ड होता है। कैटलॉग फ़ाइल में फ़ाइलें और निर्देशिकाएं उनके अद्वितीय कैटलॉग नोड आईडी (या CNID) द्वारा स्थित होती हैं।
- एक फ़ाइल थ्रेड रिकॉर्ड केवल फ़ाइल का नाम और उसकी मूल निर्देशिका का CNID संग्रहीत करता है।
- एक फ़ाइल रिकॉर्ड फ़ाइल के बारे में विभिन्न प्रकार के मेटाडेटा को संग्रहीत करता है जिसमें उसका CNID, फ़ाइल का आकार, तीन टाइमस्टैम्प (जब फ़ाइल बनाई गई थी, अंतिम बार संशोधित, अंतिम बार बैकअप किया गया), डेटा की पहली फ़ाइल विस्तार और संसाधन फोर्क्स शामिल हैं और एक्सटेंट ओवरफ़्लो फ़ाइल में फ़ाइल के पहले डेटा और संसाधन सीमा रिकॉर्ड के संकेतक। फ़ाइल रिकॉर्ड दो 16 बाइट फ़ील्ड भी संग्रहीत करता है जिनका उपयोग फ़ाइंडर द्वारा फ़ाइल के बारे में विशेषताओं को संग्रहीत करने के लिए किया जाता है, जिसमें इसके निर्माता कोड, प्रकार कोड, फ़ाइल को प्रदर्शित होने वाली विंडो और विंडो के भीतर उसके स्थान जैसी चीज़ें शामिल हैं।
- एक डायरेक्ट्री थ्रेड रिकॉर्ड केवल डायरेक्टरी का नाम और उसकी मूल निर्देशिका का CNID संग्रहीत करता है।
- एक निर्देशिका रिकॉर्ड जो निर्देशिका के भीतर संग्रहीत फ़ाइलों की संख्या, निर्देशिका की सीएनआईडी, तीन टाइमस्टैम्प (जब निर्देशिका बनाई गई थी, अंतिम बार संशोधित किया गया था, अंतिम बार बैकअप किया गया था) जैसे डेटा संग्रहीत करता है। फ़ाइल रिकॉर्ड की तरह, डायरेक्ट्री रिकॉर्ड भी फ़ाइंडर द्वारा उपयोग के लिए दो 16 बाइट फ़ील्ड संग्रहीत करता है। ये निर्देशिका की सामग्री, विंडो के डिस्प्ले मोड (आइकन दृश्य, सूची दृश्य इत्यादि) और विंडो की स्क्रॉल की स्थिति को प्रदर्शित करने के लिए उपयोग की जाने वाली विंडो के लिए चौड़ाई और ऊंचाई और x और y निर्देशांक जैसी चीजों को संग्रहीत करते हैं। छड़।
सीमाएँ
कैटलॉग फ़ाइल, जो सभी फ़ाइल और निर्देशिका रिकॉर्ड को एक ही डेटा संरचना में संग्रहीत करती है, जब सिस्टम कंप्यूटर कंप्यूटर मल्टीटास्किंग की अनुमति देता है, तो प्रदर्शन संबंधी समस्याएं उत्पन्न होती हैं, क्योंकि एक समय में केवल एक ही प्रोग्राम इस संरचना में लिख सकता है, जिसका अर्थ है कि कई प्रोग्राम प्रतीक्षा कर सकते हैं। प्रोग्राम द्वारा सिस्टम को बाधित करने के कारण कतार।[6] यह गंभीर विश्वसनीयता चिंता का विषय भी है, क्योंकि इस फ़ाइल के क्षतिग्रस्त होने से संपूर्ण फ़ाइल सिस्टम नष्ट हो सकता है। यह अन्य फ़ाइल सिस्टमों से भिन्न है जो फ़ाइल और निर्देशिका रिकॉर्ड को अलग-अलग संरचनाओं (जैसे DOS की FAT फ़ाइल सिस्टम या यूनिक्स फ़ाइल सिस्टम) में संग्रहीत करते हैं, जहाँ संरचना को डिस्क पर वितरित करने का मतलब है कि एकल निर्देशिका को नुकसान पहुँचाना आम तौर पर गैर-घातक है और डेटा संभवतः गैर-क्षतिग्रस्त भागों में रखे गए डेटा के साथ इसका पुनर्निर्माण किया जा सकता है।
इसके अतिरिक्त, 65,535 आवंटन ब्लॉकों की सीमा के परिणामस्वरूप फ़ाइलों का न्यूनतम आकार डिस्क के आकार 1/65,535वें के बराबर हो गया। इस प्रकार, कोई भी वॉल्यूम, चाहे उसका आकार कोई भी हो, अधिकतम 65,535 फ़ाइलें ही संग्रहीत कर सकता है। इसके अलावा, किसी भी फ़ाइल को आवंटन ब्लॉक आकार तक, वास्तव में आवश्यकता से अधिक स्थान आवंटित किया जाएगा। जब डिस्क छोटी थीं, तो इसका कोई परिणाम नहीं था, क्योंकि व्यक्तिगत आवंटन ब्लॉक का आकार तुच्छ था, लेकिन जैसे-जैसे डिस्क 1 जीबी के निशान तक पहुंचने लगी, किसी भी फ़ाइल द्वारा कब्जा की जा सकने वाली सबसे छोटी जगह (एक एकल आवंटन ब्लॉक) अत्यधिक बड़ी हो गई , डिस्क स्थान की महत्वपूर्ण मात्रा बर्बाद कर रहा है। उदाहरण के लिए, 1 जीबी डिस्क पर, एचएफएस के तहत आवंटन ब्लॉक का आकार 16 केबी है, इसलिए 1 बाइट फ़ाइल भी 16 केबी डिस्क स्थान लेगी। बड़ी फ़ाइलें (जैसे चित्र, डेटाबेस या ऑडियो) रखने वाले उपयोगकर्ताओं के लिए यह स्थिति कम समस्या वाली थी क्योंकि ये बड़ी फ़ाइलें अपने फ़ाइल आकार के प्रतिशत के रूप में कम स्थान बर्बाद करती थीं। दूसरी ओर, कई छोटी फ़ाइलों वाले उपयोगकर्ता, बड़े आवंटन ब्लॉक आकार के कारण प्रचुर मात्रा में स्थान खो सकते हैं। इसने मैक उपयोगकर्ताओं के लिए छोटे लॉजिकल वॉल्यूम में विभाजन डिस्क को बहुत आकर्षक बना दिया, क्योंकि छोटे वॉल्यूम पर संग्रहीत छोटे दस्तावेज़ बड़े विभाजन पर रहने की तुलना में बहुत कम जगह लेंगे। यही समस्या FAT16 फ़ाइल सिस्टम में भी मौजूद थी।
HFS उस फ़ाइल के केस को सहेजता है जिसे बनाया गया है या उसका नाम बदला गया है लेकिन संचालन में केस-असंवेदनशील है।
यह भी देखें
- फ़ाइल सिस्टम की तुलना
- एपीएफएस
- एचएफएस प्लस
संदर्भ
- ↑ Gagne, Ken (2009-08-31). "स्नो लेपर्ड के कारण विरासती डेटा खोना". Computerworld. Retrieved 2009-09-07.
- ↑ 2.0 2.1 2.2 "एचएफएस प्राइमर" (PDF). MWJ. GCSF, Incorporated. 2003-05-25. Archived from the original (PDF) on 2019-12-31.
- ↑ "What's New in macOS: macOS Sierra 10.12". Apple. Retrieved 25 January 2017.
- ↑ "MacOS कैटालिना और बाद के संस्करण पर HFS क्लासिक ड्राइव कैसे माउंट करें". Matthew Hughes. 25 July 2020. Retrieved 2 March 2022.
- ↑ "About the security content of Security Update 2021-005 Mojave". Apple Support (in English). 2022-06-21. Retrieved 2023-05-18.
- ↑ Giampaolo, Dominic (1999). Be फ़ाइल सिस्टम के साथ प्रैक्टिकल फ़ाइल सिस्टम डिज़ाइन (PDF). Morgan Kaufmann. p. 37. ISBN 1-55860-497-9. Archived from the original (PDF) on 2017-02-13. Retrieved 2006-07-13.
बाहरी संबंध
- HFS specification from developer.apple.com
- Filesystems HOWTO: HFS - slightly out of date
- HFS File Structure Explained - early description of HFS
- DiskWarrior - Software to eliminate all damage to the HFS disk directory
- MacDrive - Software to read and write HFS/HFS Plus-formatted disks on Microsoft Windows
- hfsutils - open-source software to manipulate HFS on Unix, DOS, Windows, OS/2