UNIX / Linux में निर्देशिकाओं के लिए हार्ड लिंक की अनुमति क्यों नहीं है?

Question

मैंने पाठ्य पुस्तकों में पढ़ा है कि यूनिक्स / लिनक्स निर्देशिकाओं के लिए कठिन लिंक की अनुमति नहीं देता है, लेकिन नरम लिंक की अनुमति देता है। क्या यह इसलिए है, क्योंकि जब हमारे पास साइकिल होती है और अगर हम हार्ड लिंक बनाते हैं, और कुछ समय बाद हम मूल फ़ाइल को हटा देते हैं, तो यह कुछ कचरा मूल्य को इंगित करेगा?

यदि हार्ड लिंक को अनुमति न देने के पीछे साइकिल एकमात्र कारण था, तो निर्देशिकाओं के लिए नरम लिंक की अनुमति क्यों है?

Comments

कहाँ ..इशारा करना चाहिए ? विशेष रूप से इस निर्देशिका के लिए कड़ी को हटाने के बाद, जिस निर्देशिका में इंगित किया गया है ..? इसे कहीं इंगित करने की आवश्यकता है।

— थोरबजोरन रेव एंडरसन

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

— पार्थियन शॉट

मुझे यह स्पष्टीकरण पसंद है । संक्षिप्त और पढ़ने में आसान और / या स्किम।

— ट्रेवर बॉयड स्मिथ

Answer 1

यह सिर्फ एक बुरा विचार है, क्योंकि हार्ड लिंक और मूल नाम के बीच अंतर बताने का कोई तरीका नहीं है।

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

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

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

एक हार्ड लिंक सिर्फ एक अतिरिक्त निर्देशिका प्रविष्टि है जो उस इनोड की ओर इशारा करती है। जब आप ls -l, अनुमतियों के बाद का नंबर नामित लिंक संख्या है। अधिकांश नियमित फ़ाइलों में एक लिंक होगा। एक फ़ाइल के लिए एक नया हार्ड लिंक बनाने से दोनों फ़ाइल नाम एक ही इनोड में आ जाएंगे। ध्यान दें:

% ls -l test
ls: test: No such file or directory
% touch test
% ls -l test
-rw-r--r--  1 danny  staff  0 Oct 13 17:58 test
% ln test test2
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
% touch test3
% ls -l test*
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
-rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
-rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3
            ^
            ^ this is the link count

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

% ls -li test*  
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test
14445750 -rw-r--r--  2 danny  staff  0 Oct 13 17:58 test2
14445892 -rw-r--r--  1 danny  staff  0 Oct 13 17:59 test3

-iध्वज के लिए lsआप पंक्ति के आरंभ में आईनोड संख्या को दर्शाता है। ध्यान दें कि कैसे testऔर test2एक ही इनोड संख्या है, लेकिन test3एक अलग है।

अब, यदि आपको निर्देशिकाओं के लिए ऐसा करने की अनुमति दी गई थी, तो फाइलसिस्टम में अलग-अलग बिंदुओं में दो अलग-अलग निर्देशिकाएं एक ही बात को इंगित कर सकती हैं। वास्तव में, एक उप-व्यक्ति अपने दादा-दादी के लिए एक लूप का निर्माण कर सकता है।

इस लूप की चिंता क्यों है? क्योंकि जब आप ट्रैवर्स कर रहे होते हैं, तो आपको पता लगाने का कोई तरीका नहीं होता है कि आप लूप कर रहे हैं (बिना इनवॉइस के आप ट्रैक को ट्रैक कर सकते हैं)। कल्पना कीजिए कि आप duकमांड लिख रहे हैं , जिसे डिस्क के उपयोग के बारे में पता लगाने के लिए उपखंड के माध्यम से पुनरावृत्ति करने की आवश्यकता है। duजब यह एक लूप से टकराएगा तो कैसे पता चलेगा? यह त्रुटि प्रवणता है और बहुत सारे बहीखाते जो duइस सरल कार्य को करने के लिए करना होगा।

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

तो क्यों duआसानी से और कड़ी नहीं सहानुभूति के साथ सौदा कर सकते हैं ? हम ऊपर देख पा रहे थे कि हार्ड लिंक सामान्य निर्देशिका प्रविष्टियों से अप्रभेद्य हैं। हालांकि, साइमलिंक, विशेष, पता लगाने योग्य और स्किप करने योग्य हैं!  duसिम्लिंक एक सिम्लिंक है, और इसे पूरी तरह से छोड़ देता है!

% ls -l 
total 4
drwxr-xr-x  3 danny  staff  102 Oct 13 18:14 test1/
lrwxr-xr-x  1 danny  staff    5 Oct 13 18:13 test2@ -> test1
% du -ah
242M    ./test1/bigfile
242M    ./test1
4.0K    ./test2
242M    .

Comments

Allowing hard links to directories would break the directed acyclic graph structure of the filesystem। क्या आप हार्ड लिंक का उपयोग करके चक्र के साथ समस्या के बारे में अधिक बता सकते हैं?

— सिम्बलिंक के

उन्हें लगता है कि लिंक () सिस्टम कॉल में साइकल डिटेक्शन को जोड़कर मैक पर इसकी अनुमति दी गई है, और यदि आप एक साइकल बना सकते हैं, तो आपको एक निर्देशिका हार्ड लिंक बनाने की अनुमति देने से इनकार करते हैं। एक उचित समाधान लगता है।

— psusi

@psusi mkdir -pa / b; nocheckln ca; एमवी सीए / बी; - nocheckln एक सैद्धांतिक ln है जो निर्देशिका args के लिए doesn't की जाँच करता है, और बस लिंक से गुजरता है, और क्योंकि कोई चक्र नहीं बना है, हम 'c' बनाने में सभी अच्छे हैं। तब हम 'c' को 'a / b' में ले जाते हैं, और एक चक्र a / b / c -> a / से लिंक में बनाया जाता है () लिंक पर्याप्त नहीं है

— Danny Dulai

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

— doug65536

@HiteWinterWolf, इस लिंक के अनुसार, उन्होंने विशेष रूप से टाइम मशीन के लिए इसके लिए समर्थन जोड़ा है, लेकिन केवल रूट को इसे करने की अनुमति है: superuser.com/questions/360926/…

— psusi

Answer 2

माउंट पॉइंट के अपवाद के साथ, प्रत्येक निर्देशिका में एक और केवल माता-पिता होते हैं ..:।

pwdडिवाइस की जांच करने का एक तरीका है: 'इन'। तथा '..'। यदि वे समान हैं, तो आप फ़ाइल सिस्टम की जड़ तक पहुँच चुके हैं। अन्यथा, माता-पिता में वर्तमान निर्देशिका का नाम ढूंढें, उसे एक स्टैक पर धक्का दें, और '../' की तुलना करना शुरू करें। '../ ..' के साथ, फिर '../../'। '../../ ..' आदि के साथ, एक बार जब आप रूट को हिट कर लेते हैं, तो स्टैक से नामों को पॉप करना और प्रिंट करना शुरू करें। यह एल्गोरिथ्म इस तथ्य पर निर्भर करता है कि प्रत्येक निर्देशिका में एक और केवल एक माता-पिता हैं।

यदि निर्देशिकाओं के हार्ड लिंक की अनुमति दी गई थी, तो कई माता-पिता में से किसको ..इंगित करना चाहिए ? यही कारण है कि निर्देशिकाओं के लिए हार्डलिंक की अनुमति नहीं है।

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

Comments

इस बारे में इतना निश्चित नहीं है। अगर हम ..माता-पिता के लिए वर्चुअल हार्डलिंक की तरह होने के बारे में सोचते हैं , तो कोई तकनीकी कारण नहीं है कि लिंक का लक्ष्य केवल एक अन्य लिंक हो सकता है। pwdपथ को हल करने के लिए बस एक अलग एल्गोरिथ्म का उपयोग करना होगा।

— बेनुबर्ड

Answer 3

हार्ड लिंकिंग निर्देशिकाओं का अनुकरण करने के लिए आप बाइंड माउंट का उपयोग कर सकते हैं

sudo mount --bind /some/existing_real_contents /else/dummy_but_existing_directory
sudo umount /else/dummy_but_existing_directory

Answer 4

मुझे इस प्रश्न के बारे में कुछ और बिंदु जोड़ना पसंद है। निर्देशिका के लिए हार्ड लिंक को लिनक्स में अनुमति दी जाती है, लेकिन प्रतिबंधित तरीके से।

जब हम एक निर्देशिका की सामग्री को सूचीबद्ध करते हैं, तब हम इसका परीक्षण कर सकते हैं कि हम दो विशेष निर्देशिकाओं को खोजें "।" तथा ".."। जैसा कि हम जानते हैं "।" मूल निर्देशिका के बिंदु और ".." मूल निर्देशिका के बिंदु हैं।

तो एक डायरेक्टरी ट्री बनाने की सुविधा देता है जहाँ "a" पैरेंट डायरेक्टरी होती है जिसके पास अपने बच्चे के रूप में डायरेक्टरी "b" होती है।

 a
 `-- b

निर्देशिका "a" के इनकोड को नोट करें। और जब हम ls -laडायरेक्टरी से करते हैं "a" we can see that "।" निर्देशिका भी एक ही आईनोड की ओर इशारा करती है।

797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 a

और यहां हम पा सकते हैं कि निर्देशिका "ए" में तीन हार्ड लिंक हैं। इसका कारण यह है कि इनकोड 797358 में "के नाम पर तीन हार्डलिंक हैं।" "एक" निर्देशिका और नाम "" के अंदर "निर्देशिका के अंदर" बी "और एक नाम के साथ" ए "।

$ ls -ali a/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 .

$ ls -ali a/b/
797358 drwxr-xr-x 3 mkannan mkannan 4096 Sep 17 19:13 ..

तो यहाँ हम समझ सकते हैं कि हार्डलिंक्स केवल अपने माता-पिता और बच्चे की निर्देशिकाओं से जुड़ने के लिए निर्देशिकाओं के लिए हैं। और इसलिए एक बच्चे के बिना एक निर्देशिका में केवल 2 हार्डलिंक होंगे, और इसलिए निर्देशिका "बी" में केवल दो हार्डलिंक होंगे।

एक कारण है कि स्वतंत्र रूप से निर्देशिकाओं को जोड़ने से रोकने के लिए अनंत संदर्भ छोरों से बचने के लिए होगा जो प्रोग्रामों को भ्रमित करेंगे जो कि फाइलसिस्टम को पीछे छोड़ते हैं।

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

Comments

अच्छा उदाहरण। इससे मेरा शक साफ़ हो गया। तो इन मामलों को अनंत छोरों से बचने के लिए एक विशेष तरीके से नियंत्रित किया जाता है। सही?

— जी गिल

जैसा कि हमारे पास निर्देशिकाओं "" .. "और" के लिए हार्ड लिंक की अनुमति देने का एक सीमित तरीका है। हम एक अनन्त लूप तक नहीं पहुंचेंगे और इसलिए हमें उनसे बचने के लिए किसी विशेष तरीके की आवश्यकता नहीं होगी क्योंकि वे ऐसा नहीं करेंगे :)

— कन्नन मोहन

Answer 5

निम्नलिखित में से कोई भी निर्देशिका के लिए हार्ड लिंक को अस्वीकार करने का वास्तविक कारण नहीं है; प्रत्येक समस्या को हल करना काफी आसान है:

• पेड़ की संरचना में चक्र कठिन ट्रैवर्सल का कारण बनते हैं
• कई माता-पिता, तो "असली" कौन है?
• फाइलसिस्टम कचरा संग्रह

असली कारण (के रूप में @ Thorbjorn Ravn एंडरसन द्वारा संकेत दिया) आता है जब आप हटाना से निर्देशिका द्वारा की ओर इशारा किया एक निर्देशिका है जो कई माता-पिता है, ..:

..अब किस ओर इशारा करना चाहिए ?

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

किसी भी तरह से, यह एक प्रदर्शन ओवरहेड और फ़ाइल सिस्टम मेटा डेटा और / या कोड के लिए एक अतिरिक्त जटिलता होगी , इसलिए डिजाइनरों ने इसे अनुमति नहीं देने का फैसला किया।

Comments

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

— जत्थे

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

— लेक्वेर्विग

डायर के सिम लिंक "बसे हुए अर्थ और व्यवहार का उल्लंघन करते हैं", फिर भी उन्हें अभी भी अनुमति है। इसलिए कुछ आज्ञाओं को नियंत्रित करने के लिए विकल्पों की आवश्यकता होती है कि क्या सहानुभूति लिंक का अनुसरण किया जाता है (जैसे -L में ढूँढें और cp)। जब कोई प्रोग्राम '..' का अनुसरण करता है, तो आगे भ्रम होता है, इसलिए प्वॉइंट और / बिन / pwd से आउटपुट में अंतर एक सिम्बल लिंक को ट्रेस करने के बाद होता है। कोई "यूनिक्स उत्तर" नहीं हैं; बस डिजाइन निर्णय। जैसा कि मैंने अपने उत्तर में बताया है कि यह ".." के चारों ओर घूमता है। दुर्भाग्य से, '..' का जवाब इस बात में भी नहीं दिया गया है कि बाकी सभी लोग इतने भेड़चाल के लिए मतदान कर रहे हैं।

— लेक्वेर्विग

BTW, मैं नहीं कह रहा हूँ कि मैं dirs के लिए कड़ी कड़ी के पक्ष में हूँ। हर्गिज नहीं। मैं नहीं चाहता कि मेरा दिन का काम पहले से कठिन हो।

— लेक्वेर्विग

यह वह नहीं है जो POSIX कहता है, लेकिन IMO '..' को कभी भी एक फाइलसिस्टम कॉन्सेप्ट नहीं होना चाहिए था, न कि पथों पर सिंटैक्टिक रूप से हल किया गया था, इसलिए a/..इसका हमेशा मतलब होगा .। यह URL कैसे काम करता है, btw। यह ब्राउज़र है जो '..' को हल कर रहा है, इससे पहले कि यह सर्वर को हिट कर दे। और यह बहुत अच्छा काम करता है।

— ybungalobill

Answer 6

निर्देशिकाओं पर हार्डलिंक का निर्माण अप्राप्य होगा। मान लीजिए हमारे पास:

/dir1
├──this.txt
├──directory
│  └──subfiles
└──etc

मैं इसे हार्डलिंक करता हूं /dir2।

तो /dir2अब इन सभी फ़ाइलों और निर्देशिकाओं को भी शामिल करें

क्या होगा यदि मेरा मन बदल जाता है? मैं बस नहीं कर सकता rmdir /dir2(क्योंकि यह खाली नहीं है)

और अगर मैं पुनरावर्ती रूप से हटाता हूं /dir2... तो इसे /dir1भी हटा दिया जाएगा !

IMHO यह इससे बचने के लिए काफी हद तक पर्याप्त कारण है!

संपादित करें:

टिप्पणियाँ इस पर निर्देशिका को हटाने का सुझाव देती हैं rm। लेकिन rmएक गैर-खाली निर्देशिका विफल हो जाती है, और यह व्यवहार बना रहना चाहिए, चाहे निर्देशिका हार्डलिंक हो या नहीं। इसलिए आप rmइसे अनलिंक करना नहीं कर सकते । इसके लिए एक नए तर्क की आवश्यकता होगी rm, केवल यह कहने के लिए "यदि निर्देशिका इनोड में संदर्भ संख्या> 1 है, तो केवल निर्देशिका को अनलिंक करें"।

जो, बदले में, कम से कम आश्चर्य के एक और सिद्धांत को तोड़ता है: इसका मतलब है कि मेरे द्वारा बनाई गई निर्देशिका हार्डलिंक को हटाना सामान्य फ़ाइल हार्डलिंक को हटाने के समान नहीं है ...

मैं अपनी सजा को फिर से लागू करूंगा: आगे के विकास के बिना, हार्डलिंक निर्माण अनियंत्रित होगा (जैसा कि कोई वर्तमान आदेश वर्तमान व्यवहार के साथ असंगत होने के बिना हटाने को संभाल नहीं सकता है)

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

Comments

यह एक समस्या नहीं होनी चाहिए। आपके मामले में, जब हम dir2 को हार्डलिंक बनाते हैं, तो हमें dir1 में सभी सामग्रियों के लिए हार्डलिंक बनाना होगा और इसलिए यदि हम dir2 का नाम बदलते या हटाते हैं, तो केवल इनोड में एक अतिरिक्त लिंक हट जाता है। और यह dir1 और इसकी सामग्री को प्रभावित नहीं करना चाहिए क्योंकि इनोड में एक लिंक (dir1) है।

— कन्नन मोहन

आपका तर्क गलत है। आप इसे अनलिंक करेंगे, rm -rf न करें। और अगर लिंक की संख्या 0 तक पहुंचती है, तो सिस्टम को पता होगा कि यह सभी सामग्रियों को भी हटा सकता है।

— लेटफॉर्फ़

rmवैसे भी कमोबेश यह सब (अनलिंक) कम नहीं है। देखें: unix.stackexchange.com/questions/151951/… यह वास्तव में कोई समस्या नहीं है, किसी भी अधिक से अधिक यह हार्डलिंक फ़ाइलों के साथ है। अनलिंक करने से केवल नाम का संदर्भ समाप्त हो जाता है और लिंक की संख्या घट जाती है। तथ्य यह है कि rmdirगैर-खाली निर्देशिका को नष्ट नहीं करेगा अप्रासंगिक है - यह dir1 या तो के लिए ऐसा नहीं करेगा । हार्डलिंक डेटा की प्रतियां नहीं हैं, वे एक ही वास्तविक फ़ाइल हैं, इसलिए वास्तव में dir2 फ़ाइल को "हटाना" dir1 के लिए निर्देशिका सूची को मिटा देगा। आपको हमेशा अनलिंक करने की आवश्यकता होगी।

— ब्रायनकैन

आप इसे सामान्य फ़ाइल की तरह अनलिंक नहीं कर सकते हैं, क्योंकि यदि यह खाली न हो तो rmडायरेक्ट्री इसे अनलिंक नहीं करती है। संपादित देखें।

— पियरे-ओलिवियर वेर्स

Answer 7

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

बेल लैब्स UNIX में हार्ड-लिंकिंग निर्देशिकाओं की स्वतंत्र रूप से अनुमति दी जाती थी, कम से कम V6 और V7, बर्कले या बाद के बारे में नहीं जानते। किसी ध्वज की आवश्यकता नहीं क्या आप लूप बना सकते हैं? हाँ, ऐसा मत करो। यह बहुत स्पष्ट है कि आप क्या कर रहे हैं यदि आप एक लूप बनाते हैं। यदि आप एक विमान से बाहर स्काइडाइव करने के लिए अपनी बारी का इंतजार कर रहे हैं तो आप अपने गले में बांधने का अभ्यास करें।

आज मैं इसके साथ क्या करने की उम्मीद कर रहा था, घर के लिए हार्ड-लिंक lhome था ताकि मेरे पास / घर / प्रशासक उपलब्ध हो सके या नहीं, घर में एक ऑटोआउट के साथ कवर किया गया था या नहीं, उस ऑटोमोटिव के पास एक व्यवस्थापक है जिसका नाम एडमिन / lhome है / administ। यह मुझे एक प्रशासनिक खाता रखने में सक्षम बनाता है जो मेरी प्राथमिक होम फाइल सिस्टम की स्थिति की परवाह किए बिना काम करता है। यह है लिनक्स के लिए एक प्रयोग है, लेकिन मैं यूसीबी आधारित SunOS के लिए एक समय है कि automounts ascii स्ट्रिंग स्तर पर किया जाता है पर सीखा लगता है। यह देखना मुश्किल है कि किसी भी मनमाने ढंग से एफएस के शीर्ष पर परत के रूप में उन्हें कैसे किया जा सकता है।

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

Comments

मुझे लगता है, कि हालांकि मैं गलत हो सकता है, .और ..फ़ाइल-प्रणाली में hardlinks, आधुनिक फ़ाइल-सिस्टम के लिए नहीं हैं। हालाँकि फ़ाइल-सिस्टम ड्रायवर उन्हें फेक है। यह फाइल-सिस्टम है जो हार्ड लिंकिंग डायरेक्ट्री को बंद कर देता है। पुरानी फ़ाइल-प्रणालियों के लिए यह संभव था (लेकिन खतरनाक)। आप क्या कर रहे हैं, यह देखने के लिए mount --bind, यह भी देखें mount --make…और शायद कंटेनर।

— ctrl-alt-delor

Answer 8

मैं जो इकट्ठा करता हूं, उसका मुख्य कारण यह है कि यह चल रहे कार्यक्रमों को गड़बड़ाने के बिना निर्देशिका नामों को बदलने में सक्षम होने के लिए उपयोगी है जो अन्य फ़ाइलों को संदर्भित करने के लिए उनकी कार्यशील निर्देशिका का उपयोग करते हैं। मान लीजिए आप शराब को चलाने के लिए उपयोग कर रहे थे ~/.newwineprefix/drive_c/Program Files/Firefox/Firefox.exe, और आप ~/.wineइसके बजाय पूरे उपसर्ग को स्थानांतरित करना चाहते थे । यदि किसी अजीब कारण के लिए फ़ायरफ़ॉक्स का drive_c/windowsहवाला देते हुए पहुँच रहा था ../../windows, तो उस नामकरण के ~/.newwineprefixटूटने के क्रियान्वयन का नाम बदलकर ..मूल निर्देशिका का ट्रैक एक इनकोड के बजाय टेक्स्ट स्ट्रिंग के रूप में रख दिया गया।

एक मूल माता-पिता निर्देशिका के इनोड को संचय करना प्रत्येक पथ को ट्रैक करने की कोशिश करने की तुलना में सरल होना चाहिए क्योंकि एक पाठ स्ट्रिंग और इनोड्स की एक श्रृंखला।

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

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

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