प्रतीकात्मक लिंक के साथ लिनक्स कैसे काम करता है?

Question

मेरा मतलब है कि क्या हो रहा है जब कुछ प्रक्रिया एक सिमिलिंक पढ़ना चाहती है? क्या हो रहा है जब कोई पढ़ने या लिखने की प्रक्रिया के दौरान सिम्कलिन को बदलता है?

उदाहरण के लिए: मेरे पास 2 विशाल, समान 100G फाइलें /mnt/1और हैं /mnt/2। /mnt/1सिमलिंक के माध्यम से उपलब्ध है /home/user/file। कुछ कार्यक्रम Aपढ़ना शुरू कर देता है /home/user/file। और थोड़ी देर के बाद कुछ लिंक से बदलता /mnt/1है /mnt/2, लेकिन Aअभी भी फ़ाइल पढ़ रहा है।

क्या प्रोग्राम कैश को पूर्ण पथ बताता है?

क्या यह विफल होगा और त्रुटि होगी, क्योंकि सिमलिंक को बदल दिया गया था या यह ठीक काम करेगा, जैसे कुछ भी नहीं हुआ?

क्या यह मामले में भिन्न होगा /home/user/fileएक ब्लॉक डिवाइस से जुड़ा हुआ है (उदाहरण के लिए 2 प्रतिकृति आइसकी डिस्क)?

Answer 1

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

Comments

आप फ़ाइल के सभी लिंक हटा सकते हैं और अभी भी इसे खोलते ही इसे पढ़ते रह सकते हैं। यही कारण है कि आप रिबूट किए बिना संकुल को अपग्रेड कर सकते हैं जैसे कि आपको विंडोज़ पर करना है; क्योंकि आप प्रोग्राम निष्पादन योग्य फ़ाइल को रनिंग होने पर भी rm कर सकते हैं।

— Psusi

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

— केविन

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

— भीड़

यह उत्तर एक महत्वपूर्ण बिंदु को याद करता है, कि एक सिमिलिंक में लक्ष्य फ़ाइल का नाम होता है ।

— कीथ थॉम्पसन

Answer 2

एक प्रतीकात्मक लिंक एक छोटी फ़ाइल है जिसमें एक लक्ष्य फ़ाइल का स्थान (अर्थात पथ और फ़ाइल नाम) होता है, जिसमें निर्देशिका प्रविष्टि में एक ध्वज होता है जो दर्शाता है कि यह एक सिम्लिंक है।

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

ज्यादातर मामलों में सिम्लिंक पर फ़ाइल-डेटा ऑपरेशन फ़ाइनलीफ़ल को प्रभावित करेगा (उदाहरण के लिए सिम्लिंक को पढ़ना और लिखना, फ़ाइनल-फ़ील से पढ़ेगा / लिखना होगा ) लेकिन अपवाद हैं: readlink()सिस्टम कॉल सिम्लिंक की सामग्री को स्वयं पढ़ता है।

दूसरी ओर फ़ाइल-मेटाडेटा ऑपरेशन (जैसे नाम बदलना या हटाना) आमतौर पर सिमलिंक को प्रभावित करेगा। लेकिन यहां अपवाद भी हैं: lstat()सिस्टम कॉल की तरह है stat(), सिवाय इसके कि यह फाइनलफाइल (2) के बजाय सिम्क्लिन पर ही जानकारी लौटाता है ।

---

(1) स्तरों की संख्या पर सीमा होती है और अगर सिम्कलिन में स्थान एक सापेक्ष पथ है तो चीजें थोड़ी अधिक जटिल हो जाती हैं।

(2) सिम्लिंक (7 ) पढ़ें : अधिक विवरण के लिए प्रतीकात्मक लिंक हैंडलिंग ।man 7 symlink

(3) rmकमांड या unlink()सिस्टम कॉल शारीरिक रूप से किसी फ़ाइल को नहीं हटाता है। यह निर्देशिका प्रविष्टि को हटाता है जो फ़ाइल के इनकोड को इंगित करता है। फ़ाइल स्वयं ही हटा दी जाती है, यदि दोनों ) कोई अधिक निर्देशिका प्रविष्टियाँ (हार्ड लिंक) नहीं हैं जो इसके इनोड और बी का संदर्भ देती हैं। किसी भी प्रक्रिया में फ़ाइल खुली नहीं है।

Answer 3

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

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

एक कड़ी से कड़ी के प्रतीकात्मक लिंक में अंतर यह है कि नियुक्ति एक कठिन लिंक की तरह डेटा क्षेत्रों के लिए शिकार करने के बजाय एक कड़ी है।

उदाहरण:

टेस्ट 1:

echo 'data' >file.txt

यह सेक्टर 10 से 20 * (* केवल समझाने के लिए संख्या) की ओर इशारा करते हुए हार्ड लिंक file.txt का निर्माण करेगा।

टेस्ट 2:

अब क्या होगा?

ln file.txt file_2.txt

इसने एक हार्डलिंक file_2.txt को सेक्टर 10 से 20 (फ़ाइल का समान) की ओर इशारा करते हुए बनाया, इसलिए यदि आप फ़ाइल को हटाते हैं, तो सेक्टर 10 से 20 अभी भी आरक्षित हैं, और आप फ़ाइल के अंदर डेटा देख सकते हैं। । (file.txt और file_2.txt दोनों मूल की तरह हैं)

टेस्ट 3:

ln -s file.txt file_sym.txt 

हार्ड लिंक file.txt के लिए प्रतीकात्मक प्रतीकात्मक लिंक file_sym.txt को इंगित किया है, इसलिए जब आप file_sym.txt तक पहुंचने का प्रयास करते हैं, तो आप file.txt देखेंगे, लेकिन यदि आप file.txt को हटाते हैं तो file_sym को लक्ष्य नहीं मिलेगा।

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