लिनक्स की फाइलसिस्टम को सिंगल डायरेक्टरी ट्री के रूप में क्यों बनाया गया है?

Question

क्या कोई समझा सकता है कि लिनक्स को एकल निर्देशिका पेड़ के रूप में क्यों बनाया गया है?

जबकि विंडोज में हमारे पास कई ड्राइव्स हो सकते हैं C:\, और D:\, यूनिक्स में एक ही रूट है। कोई खास वजह?

Comments

@terdon - मुझे लगता है कि वह एकल रूट निर्देशिका (/) बनाम डॉस-शैली (C: \ D: \) के बारे में पूछ रहा है।

— जोर्डनम

आप लिनक्स में (और आमतौर पर करते हैं) कई ड्राइव कर सकते हैं। वास्तव में, मूल सिद्धांत समान है, C:और D:विंडोज में भी माउंट पॉइंट हैं। विंडोज के बराबर /है My Computer, सब कुछ उसी के तहत मुहिम शुरू की है।

— terdon

मुझे लगता है कि एक अधिक प्रासंगिक सवाल यह होगा कि "एक ऑपरेटिंग सिस्टम एक रूट क्यों नहीं होगा"? (डॉस / विंडोज के लिए उत्तर भविष्य की / अनावश्यक धारणा के लिए योजना बनाने में त्रुटि / असफलता होगी)

— जोएलफैन

विंडोज ने इससे पहले एमएस-डॉस की वजह से उस विचित्र प्रणाली को चुना था, और एमएस-डॉस ने सीपी / एम द्वारा शुरुआती मिसाल कायम की थी। MS-DOS एक फ्लॉपी ड्राइव आधारित प्रणाली थी (A: और B: शुरू में, कभी-कभी उदाहरण के लिए, एकल ड्राइव सिस्टम पर, A: और B: एक ही ड्राइव थी, लेकिन स्वैप / कॉपी ऑपरेशन के प्रयोजनों के लिए दो अलग-अलग तार्किक डिस्क) । MS-DOS PC से क्षतिग्रस्त अधिकांश लोगों की तरह, ओपी को लगता है कि /लिनक्स पर C: MSDOS / Windows में समान है, जब यह वास्तव में एक ही चीज नहीं है।

— वॉरेन पी

वास्तव में C:, D:और सामान केवल डॉस और Win32 के साथ संगतता है; Windows NT आंतरिक रूप से कुछ हद तक एक यूनिक्स जैसी वस्तु पदानुक्रम है ड्राइव पत्र (और सामान्य Win32 सामान में) "असली" वस्तुओं के लिए सिर्फ सांकेतिक लिंक कर रहे हैं थे, ( c:\file.txtवास्तव में है \??\c:\file.txt, के साथ \??\c:जैसे करने के लिए एक सिमलिंक जा रहा है \device\harddisk0\partition1)। यहाँ

— मट्टियो इटालिया

Answer 1

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

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

मान लीजिए कि आपके पास एक ऐसी प्रणाली है जहां ओएस स्थिर है और एक ऐसा एप्लिकेशन है जिसमें उच्च I / O आवश्यकताएं हैं। आप SSD ड्राइव पर केवल पढ़ने के लिए / usr माउंट कर सकते हैं और / ऑप्ट (यदि ऐप वहां रहता है) डाल सकते हैं। फ़ाइल सिस्टम पदानुक्रम परिवर्तित नहीं होता है। विंडोज के तहत यह अधिक कठिन है, विशेष रूप से उन अनुप्रयोगों के साथ जो C: \ Program Files \ के तहत रहने पर जोर देते हैं

Comments

और उस (अलंकारिक) प्रश्न का उत्तर है: परंपरा। यूनिक्स की बस एक अलग परंपरा थी। विंडोज को यह डॉस से मिलता है, जो इसे सीपी / एम -80 से मिलता है, जो कई मिनीकंप्यूटर और मेनफ्रेम सिस्टम के सामान्य पैटर्न का पालन करता है। ड्राइव नाम अभी DISK0:या उससे छोटा हो गया SY:है A:।

— RBerteig

@RBerteig - हो सकता है परंपरा, विशेष रूप से विंडोज मामले में, लेकिन रोब पाईक हाइडियस नाम में यूनिक्स शैली नामकरण योजनाओं के लिए एक काफी समझाने तर्क प्रस्तुत करता है, pdos.csail.mit.edu/~rsc/pike85hideous.pdf

— ब्रूस Ediger

विंडोज एनटी के बाद से, मेरा मानना ​​है कि यूनिक्स के समान सटीक कार्य को पूरा करने के लिए विंडोज में दिए गए वर्चुअल पथ पर एक डिवाइस को माउंट करना संभव है, हालांकि यह घर के पीसी पर असामान्य है (कुछ हद तक सर्वर और व्यावसायिक तैनाती पर सामान्य)। यदि आप चाहें, तो आप इसे यूनिक्स वेम (tm) के संकेत के रूप में देख सकते हैं।

— JSB JS

@BruceEdiger मैं यह तर्क देने की कोशिश नहीं करने जा रहा हूं कि डॉस सही था। केवल यह इंगित करने के लिए कि विंडोज क्यों है, इसके संदर्भ हैं और यह केवल ऐसा कुछ नहीं है जिसे एमएस ने एक टोपी से बाहर निकाला है।

— RBerteig

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

— केविन कैथार्ट

Answer 2

यह आंशिक रूप से ऐतिहासिक कारणों से है, और आंशिक रूप से क्योंकि यह इस तरह से अधिक समझ में आता है।

मॉलटिक्स

मल्टिक्स पहले ऑपरेटिंग सिस्टम था, जो पदानुक्रमित फाइल सिस्टम को पेश करता था जैसा कि हम आज जानते हैं, इसमें निर्देशिकाओं को शामिल किया जा सकता है। RC Daley और PG Neumann द्वारा "माध्यमिक भंडारण के लिए एक सामान्य प्रयोजन फाइल सिस्टम" का हवाला देते हुए :

कागज की धारा 2 फाइलों की पदानुक्रमित संरचना प्रस्तुत करती है, जो सिस्टम के लचीले उपयोग की अनुमति देती है। इस संरचना में बहुमुखी प्रतिभा को आश्वस्त करने के लिए पर्याप्त क्षमताएं हैं। (...)

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

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

जैसा कि कई अन्य पहलुओं में, मल्टिक्स ने लचीलापन मांगा। उपयोगकर्ता फ़ाइल सिस्टम के एक उप-भाग में काम कर सकते हैं और बाकी को अनदेखा कर सकते हैं, और फिर भी अपनी फ़ाइलों को व्यवस्थित करने के लिए निर्देशिकाओं से लाभ उठा सकते हैं। अभिगम नियंत्रण के लिए भी निर्देशिकाएँ का उपयोग किया गया था - READ विशेषता ने उपयोगकर्ताओं को एक निर्देशिका में फ़ाइलों को सूचीबद्ध करने की अनुमति दी, और EXECUTE विशेषता ने उपयोगकर्ताओं को उस निर्देशिका में फ़ाइलों का उपयोग करने की अनुमति दी (यह कई अन्य सुविधाओं की तरह, यूनिक्स में रहते थे)।

मल्टीिक्स ने एकल भंडारण पूल के सिद्धांत का भी पालन किया। कागज इस पहलू पर ध्यान केंद्रित नहीं करता है। एक एकल भंडारण पूल उस समय के हार्डवेयर के साथ एक अच्छा मेल था: कोई हटाने योग्य भंडारण उपकरण नहीं थे, कम से कम कोई भी ऐसा नहीं होगा जिसके बारे में उपयोगकर्ता परवाह करेंगे। मल्टिक्स में एक अलग बैकअप स्टोरेज पूल था, लेकिन यह उपयोगकर्ताओं के लिए पारदर्शी था।

यूनिक्स

यूनिक्स ने मल्टीिक्स से बहुत प्रेरणा ली, लेकिन सादगी के उद्देश्य से जबकि मल्टीिक्स ने लचीलेपन का लक्ष्य रखा।

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

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

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

खिड़कियाँ

विंडोज अपने वंश को वापस दो वंशों तक ले जाता है: VMS , एक ऑपरेटिंग सिस्टम जो मूल रूप से VAX मिनीकंप्यूटर के लिए डिज़ाइन किया गया है , और CP / M , एक ऑपरेटिंग सिस्टम है जो शुरुआती इंटेल माइक्रो कंप्यूटर के लिए डिज़ाइन किया गया है।

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

CP / M को 64kB RAM और फ्लॉपी ड्राइव वाले कंप्यूटरों के लिए डिज़ाइन किया गया था, इसलिए यह सरलता के लिए चला गया। कोई निर्देशिका नहीं थी, लेकिन एक फ़ाइल संदर्भ में एक ड्राइव इंडिकेशन ( A:या B:) शामिल हो सकता है ।

जब MS-DOS 2.0 ने डायरेक्टरी पेश की, तो उसने ऐसा सिंटैक्स के साथ किया जो MS-DOS 1 के साथ संगत था, जो स्वयं CP / M का अनुसरण करता था। इसलिए पथ एकल-अक्षर नाम के साथ ड्राइव पर रूट किए गए थे। (साथ ही, /कमांड लाइन विकल्प शुरू करने के लिए वीएमएस और सीपी / एम में स्लैश चरित्र का उपयोग किया गया था, इसलिए एक अलग चरित्र को निर्देशिका विभाजक के रूप में उपयोग किया जाना था। यही कारण है कि डॉस और बाद में विंडोज बैकस्लैश का उपयोग करते हैं, हालांकि कुछ आंतरिक घटक भी क्रैश का समर्थन करते हैं। )।

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

Comments

हालांकि यह डिफ़ॉल्ट व्यवहार, NTFS फ़ाइल सिस्टम विंडोज के साथ भी माउंट कर सकते हैं नहीं है एक भी जड़ के तहत अपने सभी भंडारण: technet.microsoft.com/en-us/library/cc753321.aspx howtogeek.com/98195/... serverfault.com/questions / 24400 /…

— gerlos

ऐसा लगता है कि प्रासंगिक हिस्सा यह है कि एमएस-डॉस 1.0 फ्लॉपी-आधारित था। इस तरह की प्रणाली पर, (ए) यह जानना महत्वपूर्ण था कि आपकी फाइल किस भौतिक डिस्क पर है, और (बी) A:और B:आपकी फ्लॉपी ड्राइव के बीच अंतर करने के लिए एक सभ्य सम्मेलन था यदि आपके पास उनमें से दो थे। जब हार्ड ड्राइव का समर्थन MS-DOS 2.0 में जोड़ा गया था, तो ड्राइव C:पदनाम ने HD को एक बड़े फ्लॉपी के रूप में मानकर पीछे-संगतता की अनुमति दी।

— user1024

दरअसल, शुरू में सीपी / एम को 16 में चलाने के लिए डिज़ाइन किया गया था , न कि 64, केबी के रैम में। 64 केबी आंकड़ा संभवतः कुछ सांस लेने वाले कमरे को आवेदन करने की अनुमति देता है ; यदि आवश्यक हो तो कमांड प्रोसेसर (CCP) को अधिलेखित और फिर से लोड किया गया था, यदि हर समय BIOS और BDOS मेमोरी निवासी थे। हां, यह वह जगह है जहां BIOS से आता है - आईबीएम शब्द के साथ नहीं आया था! विकिपीडिया सीपी / एम देखें : हार्डवेयर मॉडल और ऑपरेटिंग सिस्टम के घटक । ध्यान रखें कि 16 KB केवल तीन घने लिखित पृष्ठों (70 पंक्तियों × 80 वर्णक्रम / रेखा × 3 पृष्ठ = 16800 बाइट्स) के बारे में है।

— बजे एक सीवी

Answer 3

एकल निर्देशिका ट्री होने के पीछे कोई सुरक्षा चिंताएं नहीं हैं।

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

यह यूनिक्स के डिजाइन के पीछे की प्रतिभा का केवल एक हिस्सा है ।

Answer 4

ध्यान दें कि MS-DOS से ड्राइव अक्षर के नाम जो आधुनिक विंडोज में बने रहते हैं, यहां एक लाल हेरिंग हैं। ड्राइव अक्षर के नाम एक फ़ाइल सिस्टम संरचना का सबसे अच्छा प्रतिनिधित्व नहीं है जिसमें कई जड़ें हैं। वे इस तरह की व्यवस्था का एक स्ट्रोमैन कार्यान्वयन हैं।

एक उचित रूप से कार्यान्वित फाइलसिस्टम जो कई जड़ों का समर्थन करता है, जैसे, संस्करणों के लिए मनमाने ढंग से नामकरण की अनुमति देगा dvdrom:/path/to/file.avi। इस तरह के सिस्टम से विंडोज को प्लेग करने वाले हंसमुख उपयोगकर्ता इंटरफ़ेस मुद्दों से छुटकारा मिल जाएगा। उदाहरण के लिए, यदि आप किसी डिवाइस जैसे कैमरा में प्लग इन करते हैं, तो विंडोज एक्सप्लोरर यूआई आपको विश्वास दिलाता है कि कैमरा (या जो भी हो) नामक एक डिवाइस है, और आपके पास एक रास्ता है Computer\Camera\DCIM\...। हालाँकि, यदि आप एक्सप्लोरर से बाहर इस पथ के शाब्दिक संस्करण को काटते और चिपकाते हैं, तो यह वास्तव में काम नहीं करता है क्योंकि कुछ पथनाम घटक उपयोगकर्ता इंटरफ़ेस फिक्शन हैं, जो अंतर्निहित ओएस के लिए ज्ञात नहीं हैं। कई जड़ों के साथ एक ठीक से लागू प्रणाली में, यह ठीक होगा: एक होगाcamera:\DCIM\...पथ जो सिस्टम में हर स्तर पर समान रूप से मान्यता प्राप्त है। इसके अलावा, यदि आपने ओएलडी पीसी से एक पुरानी हार्ड ड्राइव को पोर्ट किया है, तो आप कुछ ड्राइव अक्षर के नाम के साथ अटक नहीं जाएंगे F:, बल्कि आप इसे जो चाहें, नाम दे पाएंगे old-disk:।

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

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

गणितीय रूप से, किसी भी असंतुष्ट ट्री ग्राफ ("वन") को रूट नोड जोड़कर और अपने बच्चों के साथ असहमति के टुकड़ों को जोड़कर जोड़ा जा सकता है।

इसके अलावा, यह अधिक लचीला है कि वॉल्यूम का जड़ स्तर पर होना आवश्यक नहीं है। चूंकि कोई विशेष वाक्यविन्यास नहीं है जो वॉल्यूम को दर्शाता है (यह सिर्फ एक पथ घटक है), माउंट बिंदु कहीं भी हो सकते हैं। आप अपने मशीन के लिए तीन वर्ष डिस्क में लाने, तो आप उन्हें के रूप में हो सकता है /old-disk/one, /old-disk/twoआदि हालांकि आप चाहें तो डिस्क व्यवस्थित कर सकते हैं, जिस तरह से आप फ़ाइलों और निर्देशिकाओं का आयोजन।

अनुप्रयोगों को लिखा जा सकता है जो पथों पर निर्भर करते हैं, और पथों की वैधता को बनाए रखा जा सकता है जब भंडारण उपकरणों को पुन: कॉन्फ़िगर किया जाता है। उदाहरण के लिए, एप्लिकेशन जैसे /var/logऔर जाने-पहचाने रास्तों का उपयोग कर सकते हैं /var/lib। यह आप पर निर्भर है कि क्या /var/logऔर /var/libएक ही डिस्क वॉल्यूम पर या अलग लोगों पर कर रहे हैं। रास्तों को संरक्षित करते हुए, आप एक सिस्टम को एक नए स्टोरेज टोपोलॉजी में स्थानांतरित कर सकते हैं।

माउंट पॉइंट एक अच्छा विचार है, यही कारण है कि विंडोज 2000 के आसपास से विंडोज उनके पास है।

वॉल्यूम माउंट पॉइंट सिस्टम परिवर्तनों के खिलाफ मजबूत होते हैं जो डिवाइस को कंप्यूटर से जोड़े या हटाए जाने पर होते हैं। Microsoft तकनीक

Comments

शायद संयोग से, आपका "अच्छा मल्टी-रूट डिज़ाइन" पुराने AmigaDOS सिस्टम की तरह लगता है, जिसने मनमानी मात्रा के नामों की अनुमति दी, जिसमें "असाइन किए गए" वॉल्यूम शामिल हैं जो किसी अन्य वॉल्यूम के अंदर एक विशिष्ट निर्देशिका को संदर्भित करते हैं। आप यहां तक ​​कि (उपयुक्त सॉफ्टवेयर के साथ ) "वर्चुअल" वॉल्यूम जैसे, कह सकते हैं, एक FTP:वॉल्यूम जिसने आपको किसी भी FTP सर्वर पर पथ के साथ फ़ाइलों तक पहुंचने की अनुमति दी है FTP:hostname/path/to/file।

— इल्मरी करोनन

यह वास्तव में एक अच्छा जवाब नहीं है क्योंकि यह बहुत व्यक्तिपरक लगता है। इसकी सुंदर पीढ़ी विंडोज कोसने।

— रिग

@ रीग हालांकि यह सच हो सकता है, विंडोज अभी भी इन ड्राइव अक्षर के नाम रखने के लिए पूरी तरह से कोसने का हकदार है, जो एमएस-डॉस से वापस डेटिंग करता है। यह मल्टी-रूट फाइलसिस्टम है जिससे अधिकांश उपयोगकर्ता परिचित हैं, फिर भी हम इसका उपयोग वास्तव में सिंगल-रूट के साथ तुलना के प्रयोजनों के लिए नहीं कर सकते हैं, क्योंकि यह ऐसी प्रणाली का एक स्ट्रोमैन उदाहरण है।

— काज

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

— रिग

@ रीग ज़रूर; यह कोई और अधिक भयानक नहीं है, कहते हैं, एक चकमक तीर के माध्यम से अपना अगला रात्रिभोज प्राप्त करना। चकमक तीरहेड वास्तव में उनके उत्तराधिकार में कला के राज्य थे । आह, लेकिन उफ़, हम वास्तव में यह नहीं कह सकते हैं कि डॉस और ड्राइव लेटर्स के बारे में, क्या हम ... उपमाओं के लिए इतना कुछ कर सकते हैं।

— कज़

Answer 5

दोनों * निक्स और विंडोज अपने ड्राइव को माउंट करते हैं। विंडोज में ये स्वचालित रूप से माउंट पॉइंट्स में माउंट होते हैं, जो डिफ़ॉल्ट रूप से, आरोही वर्णमाला क्रम में होते हैं। ये चूक हैं:

• A:और B:=> फ्लॉपीज़
• C: => पहली हार्ड ड्राइव का पहला विभाजन
• D: => यदि कोई अन्य विभाजन मौजूद नहीं है तो अगला विभाजन या अगली हार्ड ड्राइव या सीडी / डीवीडी ड्राइव।

इन माउंट बिंदुओं में से प्रत्येक एक निर्देशिका है।

* Nix में, माउंट पॉइंट उपयोगकर्ता द्वारा तय किए जाते हैं। उदाहरण के लिए, मेरे पास एक विभाजन है /, और दूसरा है /home। तो, /homeएक अलग ड्राइव है, यह E:विंडोज पर कहने के बराबर होगा ।

दोनों मामलों में, विंडोज और * निक्स, माउंट पॉइंट्स अलग-अलग डायरेक्टरी हैं। अंतर केवल इतना है कि * nix में, ये अलग-अलग निर्देशिकाएं उप-निर्देशिकाएं हैं /, C:जबकि विंडोज में, प्रत्येक माउंट पॉइंट को सीधे अंडर माउंट किया जाता है /, My Computerआइए बताते हैं।

उपयोगकर्ता के दृष्टिकोण से, मुख्य लाभ यह है कि माउंट पूरी तरह से पारदर्शी हैं। मुझे यह जानने की जरूरत नहीं है कि निर्देशिका /homeवास्तव में एक अलग विभाजन पर है। मैं इसे केवल एक सामान्य निर्देशिका के रूप में उपयोग कर सकता हूं। इसके बजाय, डॉस में, मुझे इसे माउंट पॉइंट के नाम से स्पष्ट रूप से कहना होगाE:\home

दोनों प्रणालियों में बाहरी ड्राइव बहुत अधिक समान हैं। D:विंडोज के लिए और /mnt/cdromलिनक्स के लिए कहें । इनमें से प्रत्येक एक निर्देशिका है, मैं वास्तव में अंतर नहीं देखता हूं। जब आप विंडोज के तहत अपने ड्राइव में एक सीडीरॉम डालते हैं, तो डिस्क को D:लिनक्स की तरह ही माउंट किया जाता है ।

Comments

जिज्ञासा से बाहर, क्या आप जानते हैं कि अगर कोई विंडोज पर 27 ड्राइव बनाना चाहता है तो क्या होगा? विंडोज 27 वें ड्राइव को क्या कहेगा? : डी

— जोसेफ आर।

Hahaha। लगता है कि विंडोज भी ऐसा करने के लिए सुस्त है।

— जोसेफ आर।

माइनर नाइटपिक: ड्राइव अक्षर विंडोज में डिफ़ॉल्ट रूप से आरोही वर्णमाला क्रम में हैं, लेकिन वे हो सकते हैं और अक्सर नाम बदल दिए जाते हैं।

— RBerteig

@terdon: वह सिर्फ एक निर्देशिका के अंदर ड्राइव को माउंट करेगा - ठीक वैसे ही जैसे आप POSIX OSes में करते हैं।

— मट्टियो इटालिया

@ जोसेफ: कुछ बिंदु पर-मुझे यकीन नहीं है कि कब, लेकिन शायद NT- विंडोज ने निर्देशिकाओं में ड्राइव को माउंट करने की क्षमता प्राप्त की, जैसे कि यूनिक्स करता है। डिफ़ॉल्ट रूप से, कोई भी वास्तव में ऐसा नहीं करता है (जो मुझे आश्चर्यचकित करता है: nuke-and-pave reinstalls की आवृत्ति के साथ, मुझे लगता है कि एक अलग वॉल्यूम पर / घर लगाने के लिए कुछ अनुरूप होगा) अब तक लोकप्रिय हो गया होगा। हालाँकि, यदि आप ड्राइव अक्षर / संख्या / प्रतीकों से बाहर निकलते हैं, तो आपको सिस्टम में और ड्राइव जोड़ना चाहते हैं, तो आपको यही करना होगा।

— सबसे छोटा

Answer 6

मैं ऊपर दिए गए जवाबों से सहमत हूँ, विशेष रूप से डौग ओ'नील के उत्तर से, लेकिन मुझे लगता है कि वे सभी कुछ न कुछ याद करते हैं, जैसा कि एमएस-डॉस "सी:" या "ए:" जैसे स्पष्ट उपकरण माउंट बिंदुओं से होता है।

रोब पाइक ने नामों के वाक्य-विन्यास के बारे में द हिडेनस नेम लिखा , लेकिन रस कॉक्स ने इसे उबला :

नाम स्थान ... सबसे शक्तिशाली हैं जब नए सिंटैक्स को नए वाक्यविन्यास को जोड़े बिना जोड़ा जा सकता है।

एक एकल नाम स्थान जहां उपकरणों को मनमाने ढंग से लगाया जा सकता है, वास्तव में लचीले संचालन के लिए अनुमति देता है। मैं नियमित रूप से उपयोग करता हूं /mnt/sdb1और /mnt/cdromअस्थायी रूप से वर्तमान में अप्रयुक्त डिस्क या सीडी को समग्र फ़ाइल सिस्टम में रखता हूं । एनएफएस सर्वर पर होम डायरेक्टरीज़ का होना बिल्कुल भी असामान्य नहीं है, ताकि आप जिस भी मशीन में लॉग इन करें, आपको $HOMEहर जगह वही मिले ।

यह इस के लिए नीचे आता है: विशेष चीजों के लिए विशेष सिंटैक्स होने से आप क्या कर सकते हैं, इसकी निश्चित सीमाएं हैं। यदि आप केवल एक अप्रयुक्त डिस्क या सीडी या डीवीडी, या "ई:" या "डब्ल्यू:" या जो कुछ भी पर एक नेटवर्क फाइल सिस्टम / "शेयर" माउंट कर सकते हैं, तो आपको बहुत कम लचीलापन मिला है।

Comments

उसके लिए आपको वास्तव में सहानुभूति की आवश्यकता नहीं है। आप किसी भी पथ, जैसे / usr / लोकल - पर किसी पार्टीशन (या नेटवर्क स्टोरेज या जो कुछ भी) को सीधे माउंट कर सकते हैं - हालाँकि यह हमेशा मुझे चकरा देता है जब मुझे एक नेटवर्क मिलता है जहाँ / usr / लोकल पॉइंट्स एक नेटवर्क माउंट के लिए। हां, वे मौजूद हैं और ऐसा करने के लिए कुछ कारण है: / usr / स्थानीय आपके व्यवस्थापक के लिए ओएस वितरक से सामान न रखने के लिए मानक स्थानों में से एक है।

— क्रिस्टोफर क्रेतुज़िग

@Christopher Creutzig - सहमत हैं, प्रतीकात्मक लिंक मेरे उदाहरण के लिए आवश्यक नहीं है, मैं सिर्फ एक और उदाहरण में फेंकना चाहता था कि एक लचीला नामकरण स्कीमा आपके लिए कैसे काम कर सकता है। यह शायद बहुत अच्छा उदाहरण नहीं है।

— ब्रूस एडिगर

बुद्धू वेब को देखो, वैसे। proto://specifichost.domain.tld/topleveldir/middle/specificdoc.html।

— कज़

@Christopher Creutzig - मैंने कुछ स्थानों पर नेटवर्क ड्राइव के रूप में / usr / लोकल की स्थापना की है। "स्थानीय" का अर्थ है साइट पर स्थानीय, मशीन से नहीं।

— doneal24

@ काज़, मुझे लगता है कि proto://व्यवसाय एक महत्वपूर्ण आवश्यकता है। सॉफ्टवेयर के हर टुकड़े से उन सभी यूआरआई योजनाओं के बारे में जानने की उम्मीद नहीं की जा सकती है। इस प्रकार यह जानना उपयोगी हो सकता है कि स्कीम आईडी कब समाप्त होती है, और शेष यूआरआई शुरू होता है।

— एड्रियन रत्नापला

Answer 7

यह बेवक़ूफ़ी है। विंडोज में एकल पदानुक्रम बिंदु भी है। लेकिन यह छिपा हुआ है और गैर-मानक है। अधिकांश चीजों के रूप में खिड़कियां।

इस मामले में, यह "मेरा कंप्यूटर" की अवधारणा है। यह यूनिक्स में रूट (/) के बराबर है। याद रखें कि जड़ एक अवधारणा है जो कर्नेल में मौजूद है। आपको पसंद है या नहीं। जैसे खिड़कियां "मेरा कंप्यूटर" का इलाज करती हैं। बेशक, आप यूनिक्स में रूट पर एक विभाजन को माउंट कर सकते हैं, और यही वह है जो ज्यादातर लोग करते हैं। और बहुत सी चीजें चीजों के लिए एक विशिष्ट मार्ग को देखेंगी (जैसे / आदि /) लेकिन आप इसके द्वारा सीमित नहीं हैं। हर तरह से, अपने ड्राइव को / C: / में माउंट करें। आपको यूनिक्स में ऐसा करने की मनाही नहीं है।

C: \ windows में रूट नहीं है, यह एक विभाजन का आरोह बिंदु है। कौन सा शीर्ष स्तर "मेरा कंप्यूटर" पर होना चाहिए। यूनिक्स में रहते हुए आप किसी अन्य पेड़ के नीचे एक विभाजन को माउंट कर सकते हैं। तो लिनक्स में आपके पास C: घुड़सवार, /जबकि आपके पास D: माउंटेड इन /mnt/d/... या माउंटेड भी हो सकता है, /लेकिन यह काफी मुश्किल है और इस बात पर निर्भर करता है कि पहले से ही माउंटेड पथ के शीर्ष पर बढ़ते समय दो फाइल सिस्टम कैसे व्यवहार करते हैं।

तो आप ठीक उसी तरह प्राप्त कर सकते हैं जैसे आपके पास खिड़कियों के साथ "मजबूर" करके खुद को उसी सीमाओं का पालन करने के लिए है जो विंडोज़ आप पर बेतरतीब ढंग से लगाता है।

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

फिर आपको बूट विकल्पों पर माउंट विकल्पों में पास करना होगा। चूँकि आपके पास एक / etc / ... नहीं होगा, लेकिन यह भी सीमाओं को अनुकरण कर रहा है विंडोज़ लगाता है, जैसा कि वह करता है।

Comments

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

— गिल्स

@ मुझे यकीन नहीं हो रहा है। हर ड्राइवर को "माई कंप्यूटर" रूट नोड में संलग्न करना डिफ़ॉल्ट रूप से इसका उपयोग नहीं कर रहा है?

— gcb

यह केवल GUI प्रस्तुति है। फ़ाइल पथ का उपयोग नहीं करते My Computer।

— गिल्स

My Computerशेल पदानुक्रम की जड़ नोड है। इसमें ड्राइव शामिल हैं, अगर उनके पास ड्राइव लेटर है , लेकिन कंट्रोल पैनल और कोई कनेक्टेड विंडोज फोन भी है। शेल पदानुक्रम पथ के बजाय PIDL का उपयोग करता है।

— एमएसल्टर्स

@gcb: मुद्दा यह है कि शेल पदानुक्रम "सामान्य" अनुप्रयोगों में सीधे उपयोग करने योग्य नहीं है। आप CreateFile"मेरा कंप्यूटर" या अन्य शेल फ़ोल्डरों को पास नहीं कह सकते ; यह केवल शेल-संबंधित कोड, जिसे सभी कर्नेल कॉल (और इस प्रकार 90% एप्लिकेशन, चूंकि ज्यादातर भाषाओं में फ़ाइल प्रबंधन को कर्नेल फ़ाइल APIs के संदर्भ में कार्यान्वित किया जाता है) द्वारा समझा गया एक अमूर्तन है, इस सामग्री के बारे में कुछ भी नहीं जानते हैं। शेल फ़ोल्डर केवल तभी उपयोग करने योग्य होते हैं जब प्रोग्राम "मानक संवाद" (जो शेल नेमस्पेस को समझते हैं) का उपयोग करते हैं और केवल तब चयनित फ़ाइलों को सीधे "वास्तविक" (= कर्नेल-समझ) पथ पर मैप करते हैं।

— मटेयो इटालिया

Answer 8

विंडोज़ के ड्राइव लेटर होने का कारण शायद Microsoft और DOS की तुलना में अधिक है। हटाने योग्य ड्राइव के लिए पत्र असाइन करना IBM सिस्टम पर आम था, इसलिए Microsoft शायद CP / M को कॉपी करके IBM के निर्देशों पर काम कर रहा था। और शुरू में, डॉस के पास वैसे भी निर्देशिका नहीं थी।

जब MS-DOS एक या दो हटाने योग्य डिस्क और कोई निश्चित मीडिया के साथ कंप्यूटर पर नहीं चलता था, तो आपको वास्तव में निर्देशिकाओं के साथ फ़ाइल सिस्टम की आवश्यकता नहीं होती थी। एक, या शायद दो, 180 किलोबाइट डिस्क के साथ, आपके पास कभी भी पर्याप्त फ़ाइलें नहीं थीं, जिससे उन्हें व्यवस्थित करने में बहुत परेशानी हो।

https://en.wikipedia.org/wiki/Drive_letter_assignment

Comments

यह सबसे अच्छा में गलत है। CP / M ने किसी भी Microsoft / IBM-PC DOS को कई वर्षों से पहले से माना है (मेरा मानना ​​है कि IBM का मूल विचार अपने "PC" के लिए CP / M का उपयोग करना था, क्योंकि यह उस समय के बावजूद एक बहुत ही अच्छी तरह से स्थापित डी-फैक्टो औद्योगिक मानक था यह तथ्य कि विभिन्न सीपी / एम सिस्टम असंगत हो सकते हैं), और यह शायद ही विवादित है कि आईबीएम-पीसी डॉस 86-डॉस पर आधारित था जो बदले में मूल रूप से सीपी / एम का स्रोत-कोड-संगत क्लोन था ।

— बजे एक सीवी

Answer 9

दरअसल, लिनक्स यूनिक्स पर आधारित है (या यूनिक्स है, चर्चा देखें ) और यूनिक्स मेनफ्रेम वातावरण से आता है, जहां कई उपकरणों का उपयोग करना काफी स्पष्ट था। एकल निर्देशिका ट्री के भीतर बढ़ते उपकरणों से आपको अधिकतम लचीलापन प्राप्त होता है, और उन उपकरणों की संख्या सीमित नहीं होती जो ऑपरेटिंग सिस्टम एक्सेस कर सकता है।

दूसरी तरफ, ड्राइव के लिए डॉस पत्र एक पीसी के लिए 1 या 2 फ्लॉपी स्टेशनों और एकल डिस्क ड्राइव के साथ एक अच्छा डिज़ाइन है। बिग फ्लॉपी 5,25 'हमेशा A :, थोड़ा एक 3,5' हमेशा B :, होता है और डिस्क ड्राइव हमेशा C: होता है। आपको हमेशा पता होता है कि आप फ़ाइल को फ्लॉपी या कहीं डिस्क पर कॉपी करते हैं। यदि आपको शारीरिक रूप से 2 से अधिक फ्लॉपी ड्राइव और 2 (या 4) हार्ड डिस्क कनेक्ट नहीं कर सकते हैं तो आपको किसी लचीलेपन की आवश्यकता नहीं है।

डॉस डिजाइन अधिक अंत उपयोगकर्ता के अनुकूल था, जबकि यूनिक्स डिजाइन प्रशासक के अनुकूल है। अब ड्राइव अक्षर विंडोज के लिए एक बोझ हैं, उपयोगकर्ता अपने पत्र को जानने की तुलना में हटाने योग्य ड्राइव सामग्री के साथ स्वचालित रूप से खुलने वाले एक्सप्लोरर विंडो पर भरोसा करते हैं ... उबंटू वास्तव में ऐसा ही करता है।

Answer 10

यह सच नहीं है, वास्तव में। विंडोज एक और पथ योजना का उपयोग करता है (ठीक है, समान नहीं)

आसानी से पथ, डिस्क और विभाजन को याद करने के लिए "यूनिट लेटर्स" केवल कुछ हैं।

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

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

विंडोज एनटी में डिस्क, विभाजन और यूनिट अक्षरों के बीच कोई संबंध नहीं है: आप एक फ़ोल्डर में एक पूरी मात्रा को "डाल" सकते हैं (जैसे: c: \ myseconddisk पूरी भौतिक डिस्क हो सकती है!)

Comments

ARC पथ केवल बूटिंग के लिए हैं, कुछ ROM के साथ संगतता के लिए जब NT को अल्फा और MIPS में पोर्ट किया गया था। जब सिस्टम चल रहा होता है तो वह UNC रास्तों का उपयोग करता है।

— नंजलज

Answer 11

दो बातें जो मैं बताना चाहूंगा -

1. लिनक्स में हार्ड ड्राइव वास्तव में एक तरह से असाइन किए गए अक्षर / नाम हैं, जैसे / dev / sdb1। लेकिन उन्हें एकल / मूल संरचना से पहुंचने के लिए कहीं भी रखा जा सकता है
2. सबसे आम कारण है कि लोगों को (अतीत में अपने आप को) विंडोज में अलग-अलग ड्राइव करने के लिए दस्तावेज़, संगीत, कार्यक्रम आदि रखने के लिए कहीं न कहीं होना था ताकि जब विंडोज को अनिवार्य रूप से पुनर्स्थापित या प्रतिस्थापित करने की आवश्यकता हो, तो यह अपग्रेड या वायरस हो या फ़ाइल सिस्टम विफलता, अभी भी उन फ़ाइलों तक पहुँच थी। मुझे लिनक्स में यह समस्या नहीं है - फाइल सिस्टम बहुत अधिक विश्वसनीय है, ओएस तब तक नहीं टूटता है जब तक कि मेरी ओर से कुछ प्रत्यक्ष कार्रवाई या गलती नहीं होती है (ओह! खून बहने वाला किनारा रेपो, चलो कोशिश करते हैं!), और उन्नयन एफएआर सरल हैं। और, दुर्लभ मामले में मुझे फिर से स्थापित करना पड़ा, क्योंकि सभी सॉफ्टवेयर रेपो या पीपा के माध्यम से उपलब्ध थे जो मैंने जोड़े (और मैं आसानी से अपने घर की डायर को एक लाइव डिस्क के साथ कॉपी कर सकता था),

Comments

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

— doneal24

मैं इसे इस तरह से रिलेट करने की कोशिश कर रहा था, जिसे विंडोज यूजर्स समझ सकते हैं। C: विंडोज में या तो हार्ड ड्राइव नहीं है, लेकिन हर कोई इसे इस तरह से संदर्भित करता है

— ड्रेक क्लेरिस

1. आप अभी भी अपनी फ़ाइलों को बिना अक्षरों के रख सकते हैं। 2. POSIX प्रणालियों में एक हार्ड ड्राइव को एक विभाजन तालिका के बिना एक पूरे के रूप में विभाजित किया जा सकता है, और एक अंगूठे की ड्राइव में एक विभाजन तालिका हो सकती है। इसलिए हम अटैची के बजाय एक फ़ाइल में एफएस भी खतरनाक है कि भगवान केवल यह जानता है कि कौन उसके साथ आया है। नाम।

— बेहरोज

Answer 12

यदि आप इतिहास में पीछे देखें तो आप यह भी देख सकते हैं कि यूनिक्स ने ऑडियो के लिए 8 ट्रैक टेप सिस्टम और 9 ट्रैक आईबीएम डेटा सिस्टम (डेटा के लिए 8 ट्रैक / 8 बिट्स, एक समता के लिए) के समय शुरू किया था। तकनीकी रूप से बहुत ज्यादा।

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

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

9-ट्रैक-ड्राइव और ड्राइव लेटर असाइनमेंट