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

Question

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

मैंने इन आदेशों की कोशिश की:

$ ln /Some/Direcoty /home/nischay/Hard-Directory
hard link not allowed for directory
$ sudo ln /Some/Direcoty /home/nischay/Hard-Directory
[sudo] password for nischay: 
hard link not allowed for directory

मैं इसके पीछे का कारण जानना चाहता हूं। क्या यह सभी GNU / Linux डिस्ट्रोस और Unix फ्लेवर (BSD, Solaris, HP-UX, IBM AIX) या केवल उबंटू या लिनक्स के लिए ही है?

Comments

unix.stackexchange.com/questions/22394/…

— Nanne

कोशिश करो ln -F <src> <dst>और यह काम कर सकता है । निश्चित रूप से, यह यूनिक्स के पुराने संस्करणों में सुपरयूजर के लिए काम करता था। किसी को याद है कि क्या यूसीबी या सिस्टम वी था? हां, बुरी चीजें हो सकती हैं, लेकिन आमतौर पर नहीं। जैसा कि मुझे याद है, rmdirएक कठिन कड़ी को हटाने के लिए नहीं करना जानता था। हालांकि, उपयोगकर्ता भ्रमित हो सकते हैं और गलती से चीजों को हटा सकते हैं।

— स्टीव पिचर्स

@StevePitchers rmdirएक विशेष तरीके से हार्ड लिंक कैसे संभाल सकते हैं ? एक कठिन लिंक एक सामान्य लिंक है - लेकिन एक अतिरिक्त एक है। यह पता लगाना भी आसान नहीं है कि अतिरिक्त रिकॉर्डिंग के बिना एक असामान्य अतिरिक्त लिंक मौजूद है या नहीं।

— वोल्कर सिएगल

प्रत्येक नोड उस हार्ड लिंक की संख्या को संग्रहीत करता है जो इसे इंगित करता है: सामग्री केवल तब जारी होती है जब कोई लिंक शेष न हो। तो rmdirयह बता सकता है कि क्या निर्देशिका में अन्य स्थानों से लिंक हैं या नहीं। पुनरावर्ती हटाने,, rm -rदेखभाल के साथ कोडित किया जाना चाहिए, यह सुनिश्चित करने के लिए कि यह सही ढंग से कार्य करेगा यहां तक ​​कि "अनुमति अस्वीकृत" जैसी त्रुटियां भी होनी चाहिए। BTW, UCB = BSD, doh!

— स्टीव पिचर्स

मैं ln -Fनिर्देशिकाओं पर किया है और यह काम किया है। लेकिन आप फ़ाइल सिस्टम को दूषित करने के डर से निर्देशिका को बाद में हटाने का साहस नहीं करते।

— एडवर्ड फॉक

Answer 1

निर्देशिका हार्डलिंक कई तरीकों से फाइल सिस्टम को तोड़ती है

वे आपको लूप बनाने की अनुमति देते हैं

एक निर्देशिका का एक कठिन लिंक खुद के माता-पिता से जुड़ सकता है, जो एक फाइल सिस्टम लूप बनाता है। उदाहरण के लिए, ये कमांड पीछे लिंक के साथ एक लूप बना सकते हैं l:

mkdir -p /tmp/a/b
cd /tmp/a/b
ln -d /tmp/a l

डायरेक्टरी लूप वाली फाइलसिस्टम में अनंत गहराई है:

cd /tmp/a/b/l/b/l/b/l/b/l/b

इस तरह की निर्देशिका संरचना का पता लगाते समय एक अनंत लूप से बचना कुछ मुश्किल होता है (हालांकि उदाहरण के लिए POSIX को इससे findबचने की आवश्यकता होती है)।

इस तरह के हार्ड लिंक के साथ एक फ़ाइल सिस्टम अब एक पेड़ नहीं है, क्योंकि एक पेड़ को परिभाषा से, लूप नहीं होना चाहिए।

वे मूल निर्देशिका की असंदिग्धता को तोड़ते हैं

एक फाइल सिस्टम लूप के साथ, कई मूल निर्देशिका मौजूद हैं:

cd /tmp/a/b
cd /tmp/a/b/l/b

पहले मामले में, /tmp/aकी मूल निर्देशिका है /tmp/a/b।
दूसरे मामले में, /tmp/a/b/lकी मूल निर्देशिका है /tmp/a/b/l/b, जो के रूप में ही है /tmp/a/b।
तो यह दो मूल निर्देशिका है।

वे फ़ाइलें गुणा करते हैं

फ़ाइलों की पहचान पथों द्वारा की जाती है, सिमलिंक को हल करने के बाद। इसलिए

/tmp/a/b/foo.txt
/tmp/a/b/l/b/foo.txt

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

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

आपका उदाहरण

$ ln /Some/Direcoty /home/nischay/Hard-Directory
$ echo foo > /home/nischay/Hard-Directory/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ echo bar >> /Some/Direcoty/foobar.txt
$ diff -s /Some/Direcoty/foobar.txt /home/nischay/Hard-Directory/foobar.txt
$ cat /Some/Direcoty/foobar.txt
foo
bar

निर्देशिका के लिए नरम लिंक कैसे काम कर सकते हैं?

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

लेकिन अन्य परिस्थितियां हैं, जब फ़ाइलों की तुलना करने के लिए पथ का उपयोग किया जाता है। इस मामले में, पथ में प्रतीकात्मक लिंक को पहले हल किया जा सकता है, इसे न्यूनतम में परिवर्तित किया जा सकता है , और आमतौर पर एक कैनन पथ बनाने पर प्रतिनिधित्व पर सहमति व्यक्त की जाती है :

यह संभव है, क्योंकि नरम लिंक सभी को लिंक के बिना पथों तक विस्तारित किया जा सकता है। एक मार्ग में सभी नरम लिंक के साथ ऐसा करने के बाद, शेष पथ एक पेड़ का हिस्सा है, जहां एक मार्ग हमेशा असंदिग्ध होता है।

कमांड readlinkइसके विहित पथ के लिए एक मार्ग को हल कर सकती है:

$ readlink -f /some/symlinked/path

सॉफ्ट लिंक, फाइलसिस्टम के उपयोग से भिन्न होते हैं

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

---

से man readlink:

 NAME
        readlink - print resolved symbolic links or canonical
        file names

 SYNOPSIS
        readlink [OPTION]... FILE...

 DESCRIPTION
        Print value of a symbolic link or canonical file name

        -f, --canonicalize
               canonicalize by  following  every  symlink  in
               every component of the given name recursively;
               all but the last component must exist
        [  ...  ]

Comments

एक नरम लिंक यह सब क्यों नहीं कर सकता?

— तनय

@Tanay राइट, यह नरम लिंक के साथ इसी तरह के मामलों की तुलना करने के लिए विस्तार में मदद कर सकता है। मै कोशिश करुॅगा।

— वोल्कर सेगेल

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

— inetknght

बहुत अच्छा जवाब, लेकिन फिर ... Apple ने टाइम मशीन के लिए इन मुद्दों को कैसे हल किया?

— डेमियन

बहुत दिलचस्प लगता है! लेकिन मुझे इस बात का कुछ भी पता नहीं है कि मुद्दा क्या है - क्या आप मुझे संकेत दे सकते हैं?

— वोल्कर सिएगल

Answer 2

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

सिम्बलिंक्स कर सकते हैं:

• निर्देशिकाओं को इंगित करें
• गैर-मौजूद वस्तुओं की ओर इशारा करता है
• एक ही फाइल सिस्टम के बाहर फाइलों और निर्देशिकाओं को इंगित करें

हार्ड लिंक कर सकते हैं:

• उस फ़ाइल को रखें जिसे वे हटाए जाने से संदर्भित करते हैं

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

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

Comments

अंतिम अनुच्छेद के बारे में, अगर आप संपादित "की नकल की" hardlinked फ़ाइल मूल फ़ाइल भी बदल सकती है - unix.stackexchange.com/questions/70531/...

— मार्सिन

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

— मैटिक

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

— मार्क

हेक, एक सिमलिंक को कुछ भी इंगित करने की आवश्यकता नहीं है। ln -s "Don't use this directory" READMEवैध है। वास्तव में, यदि आप इसके बारे में सोचते हैं, तो एक निर्देशिका को रिलेशनल डेटाबेस के रूप में इस्तेमाल किया जा सकता है और इसमें कोई वास्तविक फाइल नहीं होती है।

— एडवर्ड फॉक

-1 इस सवाल का जवाब नहीं है, और कुछ जानकारी स्पष्ट है।

— वेजेंड्रिया

Answer 3

FYI करें, आप माउंट का उपयोग करके निर्देशिकाओं के लिए हार्ड लिंक के समान चीज़ प्राप्त कर सकते हैं:

mount -t bind /var/www /home/user/workspace/www

यह बहुत खतरनाक है क्योंकि अधिकांश उपकरण और कार्यक्रम बाध्यकारी के बारे में नहीं जानते होंगे । मैंने एक बार उपरोक्त उदाहरण में कुछ किया था और फिर आगे बढ़ा rm -rf /home/user। सौभाग्य से, वहाँ कुछ भी प्रासंगिक नहीं था /var/www।

Comments

मैंने उपयोग किया है mount --bind <src> <dest>। देखभाल के साथ उपयोग नहीं पोंछ src;)

— kachar

मुझे मिलता है:mount: unknown filesystem type 'bind'

— विसेक

बिजीबॉक्स पर, यहmount -o bind src dest

— Mat M

@ डेबियन के साथ मैटम वही

— hanshenrik

यदि आपको केवल पढ़ने के लिए माउंट करने की आवश्यकता है, तो आप माउंट बिंदु पर अनुमतियाँ सेट कर सकते हैं और rm -rfसमस्या से बच सकते हैं । superuser.com/questions/320415/…

— zanerock

Answer 4

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

Comments

हार्ड लिंक के उपयोग के मामले अच्छे हैं। यह कहना कि आपको आमतौर पर इनका उपयोग नहीं करना चाहिए यह बहुत व्यापक है।

— सैंडर स्टीफन

+2 लिंक प्रदान करने के लिए जो वास्तव में ओपी के सवाल (और मेरा) का जवाब देता है, -1 एक राय छोड़ने के लिए ("आपको आमतौर पर वैसे भी हार्ड लिंक का उपयोग नहीं करना चाहिए" - यदि इसके समर्थन के लिए लिंक थे, तो यह ठीक होगा)। जो अच्छा था, क्योंकि मैं वैसे भी +2 नहीं दे सकता। ; डी

— एमएसएन

लिंक "वे फ़ाइल-सिस्टम संरचना को तोड़ते हैं" काम नहीं करता है।

— चार्ली पार्कर

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

— ऑक्सीविवि

अच्छा किया @CharlieParker; सभी समय का सबसे अच्छा अनपेक्षित (?) विडंबनापूर्ण टिप्पणी :)

— एलिरन मलका