निर्देशिका प्रविष्टि में स्व और माता-पिता लिंक (और ..) को क्यों संग्रहीत करें?

Question

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

क्या ऑन-डिस्क डेटा संरचना में स्वयं निर्देशिका और उसके माता-पिता के लिए एक लिंक संग्रहीत करने का कोई लाभ है जो एक निर्देशिका का प्रतिनिधित्व करता है?

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

Comments

मुझे हमेशा लगा कि वे केवल वस्तुतः थे इसलिए कार्यक्रम आसानी से वर्तमान और मूल निर्देशिका तक पहुंच सकते हैं। दिलचस्प सवाल है, लेकिन क्या यह यहाँ है?

— राफेल

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

— गिल्स एसओ- बुराई को रोकना '

@ राफेल मैंने अपना प्रश्न संपादित किया है, उम्मीद है कि यह स्पष्ट होना चाहिए कि मेरा दृष्टिकोण एक एम्बेडेड ओएस डिजाइनर है। आपकी टिप्पणियों के लिए आभार।

— गिल्स एसओ- बुराई को रोकना '

Answer 1

मूल निर्देशिका के लिंक होने से मुझे अच्छी समझ है। यदि आपके पास उन्हें नहीं था, तो आपको हमेशा पूरी निर्देशिका के साथ काम करना होगा। इसलिए, उदाहरण के लिए, का /home/svick/Documents/प्रतिनिधित्व करना होगा { /, /home/, /home/svick/, /home/svick/Documents }। यदि आपने ऐसा नहीं किया, तो आप मूल निर्देशिका को बिल्कुल भी नहीं पा सकेंगे (या यह बहुत महंगा होगा)। यह न केवल अक्षम है, बल्कि खतरनाक भी है। यदि आपके पास दो ऐसी सूचियाँ हैं जो ओवरलैप करती हैं, तो वे आसानी से वंशानुक्रम कर सकते हैं यदि आपने कुछ निर्देशिका स्थानांतरित की है।

दूसरी ओर, यदि आपके पास मूल निर्देशिका का संदर्भ है, तो यह अधिक कुशल और सुरक्षित है।

मुझे वास्तव में वर्तमान निर्देशिका के लिए लिंक होने का कोई कारण नहीं दिखता है। यदि आपके पास एक ऐसी संरचना है जो कुछ निर्देशिका का प्रतिनिधित्व करती है और आप उस निर्देशिका का उपयोग करना चाहते हैं, तो उपयोग .करना हमेशा पूरी तरह अनावश्यक है। उसकी वजह से, मुझे उम्मीद है कि .लिंक वास्तव में फाइल सिस्टम संरचना में मौजूद नहीं है और केवल आभासी है।

Comments

समान टिप्पणी: यह VFS परत के बजाय प्रत्येक फाइलसिस्टम में क्यों है? अधिकांश लिनक्स फ़ाइल सिस्टम की क्या ज़रूरत है .और ..प्रविष्टियों।

— गिल्स एसओ- बुराई को रोकना '

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

— svick

@svick: गाइल्स करता नहीं माता पिता संबंध होने नहीं के साथ माता-पिता संबंध होने की तुलना करें। वह वास्तविक फाइल सिस्टम में उनकी तुलना वास्तविक फाइल सिस्टम और उपयोगकर्ता-स्थान के बीच कोड (vfs) की एक मध्यवर्ती परत द्वारा सिम्युलेटेड होने से करता है।

— रा --रग

Answer 2

आपको कम विशेष मामले मिलते हैं। कई स्थितियों में, VFS ".." को संभाल सकता है क्योंकि यह किसी अन्य निर्देशिका नाम को संभालता है।

Comments

यदि निर्देशिकाएं आभासी हैं, तो प्रोग्राम (usermode I presume) अभी भी इसे किसी अन्य निर्देशिका के रूप में संभाल सकता है। आपको वास्तव में संग्रहण स्तर पर प्रस्तुत करने के लिए लिंक की आवश्यकता नहीं है।

— आर्यभट्ट

हां, लेकिन वीएफएस लेयर में इसे क्यों नहीं हैंडल किया गया? कोई संबद्ध संग्रहण क्यों होगा?

— गिल्स एसओ- बुराई को रोकें '

लोग ऐड / रिमूव फ़ंक्शंस में खाली लिस्ट के मामले की देखभाल करने के बजाय एक प्रहरी के साथ लिंक्ड लिस्ट को क्यों लागू करते हैं?

— rgrig

@rgrig: यह केवल तब होता है जब लिंक किए गए सूची कार्यान्वयन के लिए इंटरफ़ेस उस भाषा में लिखा जाता है जो आगमनात्मक डेटा संरचनाओं (सी, जावा, आदि ...) को संभालने में असाधारण रूप से खराब है। यहां यह समस्या प्रासंगिक नहीं है क्योंकि VFS परत उपयोगकर्ता के दृष्टिकोण से सीधे सुलभ नहीं है।

— स्टीफन जिमेनेज़

@ StéphaneGimenez: यह समस्या है प्रासंगिक क्योंकि वीएफएस, है सी में लिखा

— rgrig

Answer 3

एकमात्र कारण जिसकी मैं कल्पना कर सकता हूं, वह है निम्नलिखित परिदृश्य:

1. एक फ़ाइल सिस्टम का एक मूल कार्यान्वयन समान निर्देशिका प्रारूप के साथ मौजूद था, लेकिन उस समय फ़ाइल पथ और उपनिर्देशिकाओं की धारणाओं पर विचार नहीं किया गया था (देखें पीडीपी -7 यूनिक्स फ़ाइल सिस्टम )।

2. तब लोगों ने सोचा कि पथ संकल्प और उपनिर्देशिकाएँ उपयोगी होंगी!

3. पुराने कार्यान्वयन के साथ पश्चगामी संगतता की कुछ राशि रखने के लिए, यह निर्णय लिया गया है कि .और ..किसी भी अन्य निर्देशिका की तरह डिस्क पर संग्रहीत किया जाएगा।

तो शायद हम 40 साल पुराने सॉफ्टवेयर के साथ पिछड़े-अनुकूलता के लिए उन बेकार कलाकृतियों के साथ रह गए हैं? विश्वसनीय परिदृश्य?

---

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

Answer 4

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

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