Linux इंटरव्यू: हार्ड लिंक्स (Hard Links) बनाम सिम्बोलिक लिंक्स (Symbolic Links)

प्रॉम्प्ट और लागू संदर्भ

एक सर्विस /srv/releases/v1/app.conf को डिप्लॉय करती है। यह /srv/live/pinned.conf को हार्ड लिंक के रूप में और /srv/live/current.conf को रिलेटिव सिम्बोलिक लिंक के रूप में बनाती है। ऑपरेटर द्वारा डायरेक्टरी एंट्रीज़ को रीनेम करने और बाद में हटाने से पहले एक वर्कर रिलीज़ फ़ाइल को ओपन करता है।

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

इंटरव्यूअर क्या मूल्यांकन करता है

पहला संकेत ऑब्जेक्ट मॉडल है। एक डायरेक्टरी एंट्री एक नाम को एक inode से जोड़ती है। एक हार्ड लिंक उसी inode के लिए एक अन्य डायरेक्टरी एंट्री है; कोई भी नाम मूल (original) नहीं है। एक सिम्बोलिक लिंक एक अलग फ़ाइलसिस्टम ऑब्जेक्ट है जिसका पेलोड एक पाथनाम होता है जो उपयोग किए जाने पर रिज़ॉल्व होता है।

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

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

अंतिम संकेत ऑपरेशनल निर्णय है: लिंक की पहचान और काउंट्स का निरीक्षण करना, stat को lstat से अलग पहचानना, जहां आवश्यक हो उसी फ़ाइलसिस्टम के भीतर एटॉमिक रिप्लेसमेंट करना, और अटैकर-नियंत्रित पाथ्स पर पाथनाम चेक-देन-ओपन रेस से बचना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या स्रोत और नया हार्ड-लिंक नाम एक ही माउंटेड फ़ाइलसिस्टम पर हैं? यदि नहीं, तो link EXDEV के साथ विफल हो जाता है; डेटा कॉपी करना या सिम्लिंक का उपयोग करना एक अलग समस्या का समाधान करता है।
• क्या कॉलर को एक स्थिर ऑब्जेक्ट की आवश्यकता है या एक मूवेबल नाम की? एक हार्ड लिंक एक inode को पिन करता है। एक रिलीज़ उपनाम (alias) आमतौर पर एक सिम्लिंक होना चाहिए जिसकी डायरेक्टरी एंट्री को बदला जा सके।
• क्या टारगेट एक रेगुलर फ़ाइल है या एक डायरेक्टरी? Linux आमतौर पर डायरेक्टरीज़ के लिए हार्ड लिंक्स को प्रतिबंधित करता है, जबकि एक सिम्लिंक दोनों में से किसी का भी नाम रख सकता है।
• क्या सिम्लिंक एब्सोल्यूट है या रिलेटिव? एक रिलेटिव टारगेट सिम्लिंक वाली डायरेक्टरी से रिज़ॉल्व होता है, न कि प्रोसेस की वर्तमान वर्किंग डायरेक्टरी से।
• क्या किसी प्रोसेस के पास पहले से फ़ाइल खुली होगी? किसी पाथनाम का नाम बदलने या अनलिंक करने से मौजूदा डिस्क्रिप्टर रीडायरेक्ट नहीं होता है; वह प्रोसेस खुली हुई ऑब्जेक्ट का उपयोग करना जारी रखती है।
• क्या रीडर्स के लिए यह स्विच एटॉमिक होना चाहिए? rename के साथ रिप्लेसमेंट केवल उसी माउंटेड फ़ाइलसिस्टम के भीतर एटॉमिक होता है। क्रॉस-फ़ाइलसिस्टम मूव के लिए एक अलग पब्लिकेशन प्रोटोकॉल की आवश्यकता होती है।
• क्या पाथ के घटक किसी अविश्वसनीय उपयोगकर्ता द्वारा नियंत्रित हैं? यदि हां, तो पहले lstat और उसके बाद open में रेस कंडीशन हो सकती है। ओपन ऑपरेशन को स्वयं ट्रैवर्सल पॉलिसी को लागू करना चाहिए।

30-सेकंड उत्तर का फ्रेमवर्क

“हार्ड लिंक उसी inode के लिए एक दूसरी डायरेक्टरी एंट्री है, इसलिए दोनों नाम डेटा और मेटाडेटा साझा करते हैं। एक सिम्लिंक का अपना inode होता है और यह एक पाथ संग्रहीत करता है, जो एक्सेस करने पर रिज़ॉल्व होता है। एक हार्ड-लिंक नाम हटाने से लिंक काउंट घट जाता है; ऑब्जेक्ट अन्य हार्ड लिंक्स और ओपन डिस्क्रिप्टर्स के माध्यम से जीवित रहता है। टारगेट को हटाने या रीनेम करने से सिम्लिंक डैंगलिंग (dangling) हो सकता है।

मैं ls -li, stat, lstat या readlink, और पहले से ओपन डिस्क्रिप्टर के साथ सत्यापित करूंगा। मैं एक ही फ़ाइलसिस्टम के भीतर सटीक फ़ाइल को पिन करने के लिए हार्ड लिंक का उपयोग करूंगा, रिप्लेसेबल रिलीज़ एलियास या क्रॉस-फ़ाइलसिस्टम संदर्भ के लिए सिम्लिंक का, और एटॉमिक एलियास स्विच के लिए एक अस्थायी सिम्लिंक और उसी फ़ाइलसिस्टम के rename का उपयोग करूंगा। अविश्वसनीय पाथ्स के लिए एक अलग चेक के बजाय एक एटॉमिक नो-सिम्लिंक या बिनीथ-डायरेक्टरी ओपन पॉलिसी की आवश्यकता होती है।”

स्टेप-बाय-स्टेप डीप डाइव

स्टेप 1: नाम-से-ऑब्जेक्ट मॉडल बनाएं

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

एक हार्ड लिंक उस inode में एक अन्य डायरेक्टरी एंट्री जोड़ता है। किसी भी नाम के माध्यम से बाइट्स या मोड को बदलना दूसरे के माध्यम से दिखाई देता है। इसके विपरीत, एक सिम्लिंक का अपना inode होता है और यह ../releases/v1/app.conf जैसी स्ट्रिंग संग्रहीत करता है; सामान्य पाथनाम लुकअप उस स्ट्रिंग का अनुसरण करके दूसरे नाम तक जाता है।

स्टेप 2: एक ठोस प्रयोग चलाएं

निम्नलिखित कमांड्स परिदृश्य स्थापित करते हैं। शेल फ़ाइल डिस्क्रिप्टर को जानबूझकर खुला रखा गया है:

mkdir -p /srv/releases/v1 /srv/live
printf 'version=1\n' > /srv/releases/v1/app.conf
ln /srv/releases/v1/app.conf /srv/live/pinned.conf
ln -s ../releases/v1/app.conf /srv/live/current.conf
exec 3< /srv/releases/v1/app.conf

ls -li /srv/releases/v1/app.conf /srv/live/pinned.conf
readlink /srv/live/current.conf
stat -L -c '%F %i %h' /srv/live/current.conf
stat -c '%F %i %h' /srv/live/current.conf

mv /srv/releases/v1/app.conf /srv/releases/v1/app.conf.moved
cat /srv/live/pinned.conf
cat /srv/live/current.conf
cat <&3

rm /srv/releases/v1/app.conf.moved /srv/live/pinned.conf
cat <&3
exec 3<&-

रीनेम से पहले, रिलीज़ पाथ और pinned.conf समान inode और दो का हार्ड-लिंक काउंट दिखाते हैं। readlink सिम्लिंक पेलोड को प्रिंट करता है। सामान्य stat सिम्लिंक का अनुसरण करके टारगेट तक जाता है, जबकि उदाहरण में गैर-अनुसरण (non-following) निरीक्षण स्वयं सिम्बोलिक-लिंक ऑब्जेक्ट की रिपोर्ट करता है।

स्टेप 3: रीनेम व्यवहार का अनुमान लगाएं

इस फ़ाइलसिस्टम के भीतर mv स्रोत एंट्री के लिए एक रीनेम ऑपरेशन का उपयोग करता है। inode स्थानांतरित नहीं होता है, इसलिए pinned.conf और डिस्क्रिप्टर 3 काम करना जारी रखते हैं। current.conf अभी भी ../releases/v1/app.conf संग्रहीत करता है; क्योंकि वह पुराना नाम गायब हो गया है, इसे डीरेफ़रेंस करना अब विफल हो जाता है। स्वयं सिम्लिंक का नाम बदलने से वह लिंक ऑब्जेक्ट स्थानांतरित होगा, न कि उसका टारगेट, और यह रिलेटिव पेलोड के अर्थ को बदल सकता है क्योंकि रिज़ॉल्यूशन लिंक की नई डायरेक्टरी से शुरू होता है।

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

स्टेप 4: अनलिंक और रिक्लेमेशन का अनुमान लगाएं

app.conf.moved को हटाने से एक हार्ड लिंक कम हो जाता है। pinned.conf अभी भी inode को संदर्भित करता है, इसलिए इसका डेटा बना रहता है। pinned.conf को हटाने से अंतिम डायरेक्टरी एंट्री हट जाती है, लेकिन डिस्क्रिप्टर 3 अभी भी एक ओपन संदर्भ रखता है; cat <&3 फ़ाइल को पढ़ना जारी रखता है। स्टोरेज केवल अंतिम हार्ड लिंक और अंतिम ओपन संदर्भ समाप्त होने के बाद ही रिक्लेम (पुनः प्राप्त) करने योग्य होता है।

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

स्टेप 5: फ़ाइलसिस्टम और डायरेक्टरी सीमाओं को लागू करें

एक inode संख्या केवल अपने फ़ाइलसिस्टम के अंदर अद्वितीय होती है। एक हार्ड लिंक दूसरे फ़ाइलसिस्टम से उस inode को नाम नहीं दे सकता है और link EXDEV लौटाता है। एक सिम्लिंक ऐसा पाथ संग्रहीत कर सकता है जो माउंट सीमा को पार करता है क्योंकि लुकअप एक्सेस के समय नामों को रिज़ॉल्व करता है। यह किसी डायरेक्टरी या ऐसे टारगेट का नाम भी रख सकता है जो अभी मौजूद नहीं है।

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

स्टेप 6: इनवेरिएंट (Invariant) के अनुसार चुनें

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

कोई भी लिंक अपने आप में बैकअप नहीं है। हार्ड-लिंक्ड नाम म्यूटेशन और करप्शन को साझा करते हैं। एक सिम्लिंक में कोई टारगेट डेटा नहीं होता है। बैकअप के लिए स्वतंत्र विफलता और रिटेंशन सीमाओं के साथ-साथ रीस्टोर टेस्टिंग की आवश्यकता होती है।

स्टेप 7: पहचान और सुरक्षित ट्रैवर्सल सत्यापित करें

डिवाइस और inode की तुलना करें, केवल inode की नहीं, क्योंकि विभिन्न फ़ाइलसिस्टम्स पर inode नंबर दोहराए जा सकते हैं। stat के साथ हार्ड-लिंक काउंट की जांच करें, lstat-शैली के व्यवहार के साथ सिम्लिंक का स्वयं निरीक्षण करें, readlink के साथ इसका पेलोड प्रिंट करें, और डिस्क्रिप्टर खुला होने पर सटीक रीनेम/अनलिंक अनुक्रम का परीक्षण करें।

अविश्वसनीय पाथ्स के लिए, lstat(path) के बाद open(path) एक हमलावर को कॉल्स के बीच किसी घटक को बदलने की अनुमति देता है। Linux पर, एक विश्वसनीय डायरेक्टरी डिस्क्रिप्टर के सापेक्ष ओपन करें और आवश्यक openat2 रिज़ॉल्यूशन प्रतिबंध लागू करें, जैसे कि सिम्लिंक्स को प्रतिबंधित करना या डायरेक्टरी के ऊपर एस्केप को रोकना। सुरक्षा को उस लुकअप द्वारा लागू किया जाना चाहिए जो डिस्क्रिप्टर लौटाता है।

मजबूत नमूना उत्तर

“मैं डायरेक्टरी एंट्रीज़ से शुरुआत करता हूं। app.conf और pinned.conf एक inode के लिए दो समान नाम हैं, इसलिए वे कंटेंट, अनुमतियाँ, ओनरशिप और टाइमस्टैम्प साझा करते हैं। current.conf एक अलग सिम्लिंक inode है जिसका पेलोड ../releases/v1/app.conf है। रिलेटिव पाथ /srv/live से शुरू होता है, जहां सिम्लिंक स्थित है।

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

मैं एक ही फ़ाइलसिस्टम आर्टिफ़ैक्ट को पिन करने के लिए हार्ड लिंक का उपयोग करूंगा, मूवेबल current उपनाम के लिए सिम्लिंक का, और स्वतंत्र रिटेंशन के लिए एक वास्तविक कॉपी का। मैं एक अस्थायी सिम्लिंक बनाकर और उसी डायरेक्टरी में एटॉमिक रूप से इसका नाम बदलकर current को अपडेट करूंगा। मैं परिणाम को डिवाइस/inode, लिंक काउंट, readlink, एक डैंगलिंग-लिंक एक्सेस, और एक ओपन-डिस्क्रिप्टर टेस्ट के साथ सिद्ध करूंगा। यदि पाथ अविश्वसनीय है, तो मैं ओपन के दौरान ही नो-सिम्लिंक और डायरेक्टरी-सीमा नियमों को लागू करूंगा।”

सामान्य गलतियाँ

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

फॉलो-अप प्रश्न और उत्तर

फॉलो-अप 1: क्या हार्ड लिंक्स की अलग अनुमतियाँ या ओनर्स होते हैं?

नहीं। अनुमतियाँ, ओनर, साइज़ और टाइमस्टैम्प साझा inode से संबंधित होते हैं। एक हार्ड लिंक के माध्यम से उन्हें बदलने से वह सब बदल जाता है जो प्रत्येक साथी देखता है। डायरेक्टरी-एंट्री नाम और उनकी पैरेंट-डायरेक्टरी अनुमतियाँ अलग होती हैं; किसी नाम को रीनेम या अनलिंक करना उसकी डायरेक्टरी द्वारा नियंत्रित होता है।

फॉलो-अप 2: स्थानांतरित होने के बाद रिलेटिव सिम्लिंक कभी-कभी क्यों टूट जाता है?

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

फॉलो-अप 3: क्या rename फ़ाइलसिस्टम्स के पार current को एटॉमिक रूप से बदल सकता है?

नहीं। Linux rename माउंटेड फ़ाइलसिस्टम्स के पार EXDEV लौटाता है। गंतव्य फ़ाइलसिस्टम के भीतर पूर्ण टारगेट को प्रकाशित करें, वहां अस्थायी उपनाम बनाएं, फिर उसी डायरेक्टरी में current पर उस उपनाम का नाम बदलें। किसी भी पूर्व कॉपी चरण के लिए क्लीनअप और रिकवरी को परिभाषित करें।

फॉलो-अप 4: अंतिम पाथनाम हटाए जाने के बाद भी डिस्क स्थान क्यों उपयोग में रहता है?

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

फॉलो-अप 5: stat, lstat, और readlink में क्या अंतर है?

stat सामान्य रूप से अंतिम सिम्लिंक का अनुसरण करता है और टारगेट की रिपोर्ट करता है। lstat सिम्लिंक ऑब्जेक्ट की रिपोर्ट करता है। readlink इसे रिज़ॉल्व किए बिना इसके संग्रहीत पाथनाम को लौटाता है। उपनाम और वर्तमान में पहुंचने वाले ऑब्जेक्ट दोनों को साबित करते समय तीनों अवधारणाओं का उपयोग करें।

फॉलो-अप 6: आप अपलोड डायरेक्टरी में सिम्लिंक रेस को कैसे रोकेंगे?

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