प्रतीकात्मक लिंक और हार्ड लिंक के बीच अंतर क्या है?

Question

हाल ही में नौकरी के साक्षात्कार के दौरान मुझसे यह पूछा गया था। मैं ईमानदार था और कहा कि मुझे पता था कि एक प्रतीकात्मक लिंक कैसे व्यवहार करता है और एक कैसे बना सकता है, लेकिन एक कड़ी का उपयोग समझ में नहीं आता है और यह कैसे एक प्रतीकात्मक से अलग होता है।

Comments

'हार्ड लिंक के उपयोग को न समझें' के बारे में, इसका उपयोग बिल्ड सिस्टम में किया जा सकता है जो बायनेरिज़ की बहुत नकल करते हैं। वास्तविक प्रतिलिपि के बजाय हार्ड लिंक बनाना चीजों को गति देता है। MSBuild 4.0 इसका समर्थन करता है।

— अंकुश

मुझे इसे समझने के लिए यह लिंक बहुत उपयोगी है। askubuntu.com/questions/108771/…

— kta

unix.stackexchange के पास बुलेट पॉइंट्स की एक अच्छी सूची है ... बहुत मददगार है क्योंकि यह सभी बाधाओं को बहुत संक्षिप्त रूप से हल करता है और स्किम करना आसान है। (इनमें से बहुत से बुलेट पॉइंट्स एज केस / कैविटीज को कवर करते हैं जो केवल इस प्रश्न की टिप्पणियों में उल्लिखित हैं ... या बिल्कुल उल्लेख नहीं किया गया है)

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

Answer 1

फ़ाइल सिस्टम के नीचे, फ़ाइलों को इनोड्स द्वारा दर्शाया गया है। (या यह कई इनोड है? निश्चित नहीं है।)

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

जब आप कोई फ़ाइल हटाते हैं, तो यह अंतर्निहित इनकोड के एक लिंक को हटा देता है। जब केवल इनोड के सभी लिंक हटा दिए गए हों, तो इनोड केवल डिलीट (या डिलीट करने योग्य / ओवर-राइट) होता है।

एक प्रतीकात्मक लिंक फाइल सिस्टम में एक और नाम का लिंक है।

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

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

Comments

मुझे यकीन है कि आई-नोड ओएस के विशेष संस्करण पर निर्भर करता है; हालाँकि, मेरा मानना ​​है कि यह आमतौर पर एक एकल आई-नोड है। आई-नोड में फ़ाइल और जानकारी के बारे में जानकारी है कि डेटा डिस्क पर कहाँ संग्रहीत है। बड़ी फ़ाइलों में अतिरिक्त टेबल के लिए अप्रत्यक्ष संकेत होंगे।

— terson

आप उपयोगी सुविधा जोड़ना चाहते हैं जो प्रतीकात्मक लिंक फाइल सिस्टम को पार कर सकते हैं, हार्ड लिंक नहीं कर सकते हैं (उन्हें एक ही फाइल सिस्टम पर एक फाइल को संदर्भित करना होगा)।

— paxdiablo

लिनक्स गजट पर

— रॉड्रिग

मैंने उस पर एक ब्लॉग भी लिखा, कुछ पढ़ने और प्रयोगों के बाद csharpbsharp.tumblr.com

— अदनान भट्टी

@zen: आप किसी भी समय फ़ाइल सिस्टम को अनमाउंट / रिमाउंट कर सकते हैं, जिसका उपयोग नहीं किया जा रहा है। रूट विभाजन के लिए यह थोड़ा मुश्किल है, लेकिन यह किया जा सकता है (पुनः शामिल नहीं)। रूट के लिए ऐसा करने के लिए यह आमतौर पर सबसे अच्छा है एक रेस्क्यू सीडी के बूट को पहले माउंट और रि-बूट को संशोधित करें। लेकिन आपको सुपर यूजर पर इस तरह का सवाल पूछना चाहिए।

— मार्टिन यॉर्क

Answer 2

कुछ अच्छे अंतर्ज्ञान जो किसी भी लिनक्स (ish) कंसोल का उपयोग करने में मदद कर सकते हैं।

दो फ़ाइलें बनाएँ:

$ touch foo; touch bar

उनमें कुछ डेटा दर्ज करें:

$ echo "Cat" > foo
$ echo "Dog" > bar

(वास्तव में, मैं पहली जगह में इको का उपयोग कर सकता था, क्योंकि यह फ़ाइलों को बनाता है यदि वे मौजूद नहीं हैं ... लेकिन ऐसा कभी नहीं हुआ।)

और जैसा कि अपेक्षित था:

$cat foo; cat bar
Cat
Dog

चलो कड़ी और सॉफ्ट लिंक बनाते हैं:

$ ln foo foo-hard
$ ln -s bar bar-soft

आइए देखें कि क्या हुआ:

$ ls -l

foo
foo-hard
bar
bar-soft -> bar

फू का नाम बदलने से कोई फर्क नहीं पड़ता:

$ mv foo foo-new
$ cat foo-hard
Cat

foo- हार्ड पॉइंट इनोड, कंटेंट, फाइल का - जो कि बदला नहीं गया था।

$ mv bar bar-new
$ ls bar-soft
bar-soft
$ cat bar-soft  
cat: bar-soft: No such file or directory

फ़ाइल की सामग्री नहीं मिल सकी क्योंकि नरम लिंक उस नाम को इंगित करता है, जिसे परिवर्तित किया गया था, और सामग्री को नहीं।

इसी तरह, यदि fooहटा दिया गया है, तब foo-hardभी सामग्री रखता है; यदि barहटा दिया गया है, तो bar-softएक गैर-मौजूदा फ़ाइल का एक लिंक है।

Comments

क्या इसका मतलब यह है कि "फाइल" और "हार्ड लिंक" समान हैं, दोनों एक इनोड की ओर इशारा करते हैं? फ़ाइल या हार्ड लिंक को हटाने पर, सामग्री अभी भी मौजूद है जब तक कि कोई अभी भी इनोड को सही इंगित कर रहा है?

— डैनियल डब्ल्यू।

@DanFromGermany सही है। जब तक कम से कम एक हार्ड लिंक (यानी, फ़ाइल) की ओर इशारा किया जाता है तब तक यह सामग्री उपलब्ध रहती है।

— एडम मटन

touch blah1; touch blah2को छोटा किया जा सकता हैtouch blah1 blah2

— दिमित्री जैतसेव

@DmitriZaitsev सच है, लेकिन यह शुरुआती IMO के लिए कम पठनीय होगा।

— एडम मतान

मुझे लगता है कि यह मेरे द्वारा पढ़े गए कई उत्तरों के संबंध में सबसे अच्छा समझ में आने वाला उत्तर है। स्पष्टीकरण पाठ के गुच्छा से एक नमूना बेहतर है।

— स्कॉट चू

Answer 3

जैसा कि कहा जाता है, एक तस्वीर एक हजार शब्दों के लायक है। यहां बताया गया है कि मैं इसकी कल्पना कैसे करता हूं:

इस प्रकार हम उस चित्र को प्राप्त करते हैं:

1. myfile.txtफ़ाइल सिस्टम में एक नाम बनाएँ जो एक नए इनोड की ओर इंगित करता है (जिसमें फ़ाइल के लिए मेटाडेटा शामिल है और डेटा के ब्लॉक को इंगित करता है जिसमें इसकी सामग्री है, अर्थात पाठ "हैलो, वर्ल्ड!"

   $ echo 'Hello, World!' > myfile.txt
   

2. my-hard-linkफ़ाइल के लिए एक कठिन लिंक बनाएं myfile.txt, जिसका अर्थ है "एक ऐसी फ़ाइल बनाएं जो उसी इनोड को myfile.txtइंगित करे जो":

   $ ln myfile.txt my-hard-link
   

3. my-soft-linkफ़ाइल के लिए एक सॉफ्ट लिंक बनाएं myfile.txt, जिसका अर्थ है "एक फ़ाइल बनाएं जो फ़ाइल को इंगित करे myfile.txt":

   $ ln -s myfile.txt my-soft-link
   

देखो कि अब क्या होगा यदि myfile.txtहटा दिया गया है (या स्थानांतरित): my-hard-linkअभी भी उसी सामग्री को इंगित करता है, और इस प्रकार अप्रभावित है, जबकि my-soft-linkअब कुछ भी नहीं इंगित करता है। अन्य उत्तर प्रत्येक के पेशेवरों / विपक्षों पर चर्चा करते हैं।

Comments

@ThunderWiring "बिंदु" से, मेरा मतलब है जो भी लिंक संदर्भ। कड़ी कड़ी के मामले में, यह सीधे एक आईनोड को संदर्भित करता है (यानी उसी इनोड को जिसके द्वारा संदर्भित किया जाता है myfile.txt)। सॉफ्ट लिंक के लिए, यह संदर्भ नहीं है इनोड (जिसमें डेटा होता है), बल्कि यह संदर्भ है फ़ाइल सिस्टम पथ myfile.txt(जैसे /home/Documents/myfile.txt)

— akivajgordon

मुझे वास्तव में आपकी दृश्य प्रतिक्रिया @akivajgordon पसंद है - वास्तव में मुझे मतभेदों को बेहतर ढंग से समझने में मदद मिली!

— wmock

दस हजार शब्द!

— सगनरिटिकल

शायद मैं धीमा हूं, लेकिन आपकी तस्वीर ने लगभग 2 सेकंड में 20 साल के रहस्य को साफ कर दिया।

— jdk1.0

सबसे उपयोगी उत्तर, मैं पागल हूँ इस पोस्ट में इतनी गहराई से दफन किया गया है। मैं आपको सौ इंटरनेट पॉइंट देता हूं लेकिन दुख की बात है कि मैं आपको केवल एक ही दे सकता हूं।

— 19

Answer 4

जब मूल फ़ाइल को चारों ओर ले जाया जा रहा हो तो हार्ड लिंक उपयोगी होते हैं। उदाहरण के लिए, फ़ाइल को बिन से / usr / bin या / usr / स्थानीय / बिन पर ले जाना। / बिन में फ़ाइल के लिए कोई भी सिमलिंक इससे टूट जाएगा, लेकिन एक हार्डलिंक, फ़ाइल के लिए सीधे इनोड के लिए एक लिंक होने के नाते, परवाह नहीं करेगा।

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

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

मुझे यह भी लगता है कि मिमीप (2) और यहां तक ​​कि खुली (2) जैसी चीजें एक ही कार्यक्षमता का उपयोग करती हैं क्योंकि फाइल के इनोड को सक्रिय रखने के लिए हार्डलिंक का उपयोग किया जाता है, ताकि भले ही फाइल अनलिंक (2) एड हो जाए, इनोड प्रक्रिया को जारी रखने की अनुमति देने के लिए बनी रहे, और केवल एक बार प्रक्रिया बंद हो जाने के बाद यह फ़ाइल वास्तव में चली जाती है। यह बहुत अधिक सुरक्षित अस्थायी फ़ाइलों के लिए अनुमति देता है (यदि आप खुले रूप से प्राप्त कर सकते हैं और एटोमिक रूप से अनलिंक कर सकते हैं, जिसके लिए POSIX API हो सकता है, जो मुझे याद नहीं है, तो आपके पास वास्तव में एक सुरक्षित अस्थायी फ़ाइल है) जहाँ आप पढ़ / लिख सकते हैं बिना किसी का उपयोग किए आपका डेटा इसे एक्सेस कर सकता है। खैर, इससे पहले कि यह सच था / proc ने सभी को आपकी फ़ाइल डिस्क्रिप्टर को देखने की क्षमता दी, लेकिन यह एक और कहानी है।

जिसमें से बोलते हुए, प्रक्रिया ए में खुली हुई एक फ़ाइल को पुनर्प्राप्त किया जाता है, लेकिन फ़ाइल सिस्टम पर अनलिंक इनकोड लिंक को फिर से बनाने के लिए हार्डलिंक्स का उपयोग करने के लिए घूमता है, इसलिए जब यह प्रक्रिया खुली होती है तो फ़ाइल बंद नहीं होती है या चली जाती है।

Answer 5

नरम लिंक :

मुलायम या प्रतीकात्मक मूल फ़ाइल के लिए एक छोटा कट अधिक होता है .... यदि आप मूल को हटाते हैं तो शॉर्टकट विफल हो जाता है और यदि आप केवल लघु कट को हटाते हैं तो मूल कुछ भी नहीं होता है।

सॉफ्ट लिंक सिंटैक्स :ln -s Pathof_Target_file link

आउटपुट: link -> ./Target_file

प्रमाण: आउटपुट readlink link में भी ls -l linkआपको पहला अक्षर l केlrwxrwxrwx रूप में दिखाई देगा, जो संकेत करता है कि फ़ाइल एक सॉफ्ट लिंक है।

लिंक हटाना: unlink link

नोट: यदि आप चाहें, तो आपका सॉफ्टलिंक वर्तमान डायर से कहीं और ले जाने के बाद भी काम कर सकता है। सुनिश्चित करें कि आप नरम लिंक बनाते समय निरपेक्ष पथ दें, न कि सापेक्ष पथ। (यानी / रूट / यूजर / टारगेट_फाइल और नॉट / टारगेट_फाइल से शुरू)

कड़ी:

हार्ड लिंक मिरर कॉपी या एक ही फाइल के कई रास्तों से अधिक है। File1 के लिए कुछ करें और यह फ़ाइल 2 में दिखाई देता है। एक को हटाना अभी भी दूसरे को ठीक रखता है।

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

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

कड़ी कड़ी वाक्य रचना :ln Target_file link

आउटपुट: नाम लिंक के साथ एक फाइल उसी कोड के साथ बनाई जाएगी जो टारगेटाइल के रूप में है।

प्रमाण: ls -i link Target_file (उनके आयतों की जाँच करें)

लिंक हटाना: rm -f link (सामान्य फ़ाइल की तरह लिंक हटाएं)

नोट : प्रतीकात्मक लिंक फ़ाइल सिस्टम को फैला सकते हैं क्योंकि वे बस किसी अन्य फ़ाइल का नाम हैं। जबकि हार्ड लिंक केवल उसी फाइल सिस्टम के भीतर मान्य हैं।

प्रतीकात्मक लिंक में कुछ विशेषताएं हैं कड़ी लिंक गायब हैं:

• फ़ाइल सामग्री के लिए हार्ड लिंक बिंदु। जबकि सॉफ्ट लिंक फ़ाइल के नाम की ओर इशारा करता है।
• जबकि हार्ड लिंक का आकार सामग्री का आकार है, जबकि सॉफ्ट लिंक में फ़ाइल नाम का आकार है।
• हार्ड लिंक समान आईनोड को साझा करते हैं। नरम लिंक नहीं है।
• हार्ड लिंक फाइल सिस्टम को पार नहीं कर सकते हैं। सॉफ्ट लिंक करते हैं।

• आप तुरंत जानते हैं कि जहां एक प्रतीकात्मक लिंक कठिन लिंक के साथ इंगित करता है, आपको उसी इनोड को साझा करने वाली फ़ाइलों को खोजने के लिए पूरे फ़ाइल सिस्टम का पता लगाने की आवश्यकता है।

  # find / -inum 517333

  /home/bobbin/sync.sh
  /root/synchro
  

• हार्ड-लिंक निर्देशिकाओं को इंगित नहीं कर सकते हैं।

हार्ड लिंक की दो सीमाएँ हैं:

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

Comments

"जबकि हार्ड लिंक का आकार सामग्री का आकार है, जबकि नरम लिंक का फ़ाइल नाम आकार है।" बस स्पष्ट करने के लिए, एक और कड़ी बनाना केवल कुछ बाइट्स द्वारा मुक्त स्थान को प्रभावित करता है।

— इंगो

Answer 6

कड़ी कड़ी और प्रतीकात्मक कड़ी के बीच अंतर देखने का एक सरल तरीका एक सरल उदाहरण के माध्यम से है। किसी फ़ाइल का हार्ड लिंक उस जगह को इंगित करेगा जहाँ फ़ाइल संग्रहीत है, या उस फ़ाइल का इनकोड। एक प्रतीकात्मक लिंक वास्तविक फ़ाइल को ही इंगित करेगा।

इसलिए अगर हमारे पास "a" नामक एक फाइल है और एक हार्ड लिंक "b" और एक प्रतीकात्मक लिंक "c" बनाएं, जो सभी "a" फाइल को देखें:

echo "111" > a
ln a b
ln -s a c

"A", "b", और "c" का आउटपुट होगा:

cat a --> 111
cat b --> 111
cat c --> 111

अब फाइल "a" को हटाते हैं और देखते हैं कि "a", "b", और "c" के आउटपुट में क्या होता है:

rm a
cat a --> No such file or directory
cat b --> 111
cat c --> No such file or directory

तो क्या हुआ?

क्योंकि फ़ाइल "c" "ए" फाइल करने के लिए खुद को इंगित करता है, अगर फ़ाइल "ए" हटा दी जाती है, तो फ़ाइल "सी" को इंगित करने के लिए कुछ भी नहीं होगा, वास्तव में यह भी हटा दिया जाता है।

हालांकि, फ़ाइल "बी" भंडारण के स्थान पर, या फ़ाइल "इन" के इनोड को इंगित करता है। इसलिए यदि फ़ाइल "a" हटा दी जाती है, तो यह अब इनोड को इंगित नहीं करेगा, लेकिन क्योंकि फ़ाइल "b" करता है, इनोड तब तक संग्रहित करता रहेगा, जब तक कि कोई भी सामग्री "a" से संबंधित न हो, जब तक कि कोई और अधिक हार्ड लिंक इंगित नहीं करता है।

Comments

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

— चोलथी पॉल टिटोपिक

Answer 7

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

हार्ड लिंक एक इनोड में अतिरिक्त बिंदु होते हैं, जिसका अर्थ है कि वे केवल उसी मात्रा में लक्ष्य के रूप में मौजूद हो सकते हैं। किसी फ़ाइल के लिए अतिरिक्त हार्ड लिंक एक फ़ाइल को संदर्भित करने के लिए उपयोग किए जाने वाले "मूल" नाम से अप्रभेद्य हैं।

Comments

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

— njsf

Answer 8

मैं आपको विकिपीडिया की ओर संकेत करूंगा:

• प्रतीकात्मक लिंक
• कड़ी कड़ी

कुछ बिंदु:

• साइलिंक, हार्ड लिंक के विपरीत, फाइलसिस्टम को पार कर सकता है (ज्यादातर समय)।
• Symlinks निर्देशिकाओं को इंगित कर सकते हैं।
• हार्ड लिंक एक फ़ाइल की ओर इशारा करते हैं और आपको एक से अधिक नाम वाले एक ही फाइल को संदर्भित करने में सक्षम करते हैं।
• जब तक कम से कम एक लिंक है, तब तक डेटा उपलब्ध है।

Comments

सिद्धांत रूप में (और कुछ मामलों में व्यवहार में भी) कठिन लिंक निर्देशिकाओं को इंगित कर सकते हैं (वास्तव में "" वर्तमान निर्देशिका की एक कड़ी है और ".." मूल निर्देशिका की एक कड़ी है)। लेकिन वे खतरनाक हो सकते हैं, इसलिए अधिकांश यूनिक्स उन्हें अनुमति नहीं देते हैं (या आपको इसे लेने के लिए विशेष कदम उठाने की आवश्यकता है)। Apple उन्हें उदाहरण के लिए अपने टाइम मशीन कार्यान्वयन के लिए उपयोग करता है: earthlingsoft.net/ssp/blog/2008/03/x5_time_machine

— Joachim Sauer

आप एक लेख के लिंक की ओर इशारा कर रहे हैं ... क्या यह आपको प्रतीकात्मक लिंक बनाता है?

— इयान कैंपबेल

@JoachimSauer क्या आपको लगता है कि नई Apple फ़ाइल सिस्टम निर्देशिका के लिए हार्ड लिंक का उपयोग करने के लिए टाइम मशीन की आवश्यकता को समाप्त कर देगा?

— cjm

मैंने पाया कि विकिपीडिया की व्याख्या सबसे अच्छी श्रेणी के उत्तरों में स्पष्टीकरण की तुलना में काफी कम और अधिक ठोस है।

— लेकसियर

Answer 9

वृद्धिशील बैकअप करते समय हार्ड लिंक बहुत उपयोगी होते हैं। उदाहरण के लिए, rsnapshot देखें । हार्ड लिंक का उपयोग करके प्रतिलिपि बनाने का विचार है:

• बैकअप नंबर n से n + 1 पर कॉपी करें
• बैकअप n - 1 से n कॉपी करें
• ...
• बैकअप 0 से बैकअप 1 पर कॉपी करें
• किसी भी परिवर्तित फ़ाइलों के साथ बैकअप 0 अद्यतन करें।

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

Answer 10

इस इमेज के द्वारा हार्ड लिंक बनाम सॉफ्ट लिंक को आसानी से समझाया जा सकता है।

Comments

मुझे लगता है कि आपकी सॉफ्ट लिंक तस्वीर सही नहीं है। पॉइंट: सॉफ्ट लिंक का इनडायरेक्ट ओरिजिनल फाइल के इनोड की ओर इशारा नहीं करना चाहिए। यदि आप मूल फ़ाइल का नाम बदलते हैं, तो संबंधित सॉफ्ट लिंक मृत है

— percy507

@ percy507 हाँ आप सही हैं - लेकिन मुझे अभी भी यह एक बहुत अच्छी और सहज व्याख्या लगती है। जरा सोचिए कि इनोड के बीच तीर नहीं है ...

— माइकल लिट्विन

Answer 11

मैं निक के सवाल पर जोड़ता हूं: जब हार्ड लिंक उपयोगी या आवश्यक होते हैं? एकमात्र आवेदन जो मेरे दिमाग में आता है, जिसमें प्रतीकात्मक लिंक काम नहीं करेंगे, एक विकृत वातावरण में एक सिस्टम फ़ाइल की एक प्रति प्रदान कर रहा है।

Comments

विभिन्न स्थानों पर अलग-अलग स्थानों पर वितरित सिस्टम w / माउंट पॉइंट। बेशक, यह सिस्टम के अनुरूप होने के कारण डिज़ाइन किया जा सकता है।

— terson

मुझे लगता है कि @Tanktalus ने एक शानदार उदाहरण प्रदान किया।

— Nick Stinemates

Answer 12

से MSDN ,

प्रतीकात्मक लिंक

एक प्रतीकात्मक लिंक एक फ़ाइल-सिस्टम ऑब्जेक्ट है जो किसी अन्य फ़ाइल सिस्टम ऑब्जेक्ट को इंगित करता है। जिस वस्तु को इंगित किया जा रहा है उसे लक्ष्य कहा जाता है।

प्रतीकात्मक लिंक उपयोगकर्ताओं के लिए पारदर्शी हैं; लिंक सामान्य फ़ाइलों या निर्देशिकाओं के रूप में दिखाई देते हैं, और उपयोगकर्ता या एप्लिकेशन द्वारा बिल्कुल उसी तरीके से कार्य किया जा सकता है।

प्रतीकात्मक लिंक UNIX ऑपरेटिंग सिस्टम के साथ माइग्रेशन और एप्लिकेशन संगतता में सहायता के लिए डिज़ाइन किए गए हैं। Microsoft ने UNIX लिंक की तरह ही कार्य करने के लिए अपने प्रतीकात्मक लिंक को लागू किया है।

प्रतीकात्मक लिंक या तो पूर्ण या सापेक्ष लिंक हो सकते हैं। निरपेक्ष लिंक वे लिंक हैं जो पथ नाम के प्रत्येक भाग को निर्दिष्ट करते हैं; सापेक्ष लिंक निर्धारित किए जाते हैं जहां रिश्तेदार-लिंक विनिर्देशक एक निर्दिष्ट पथ में हैं

निरपेक्ष प्रतीकात्मक लिंक का एक उदाहरण

X: "C:\alpha\beta\absLink\gamma\file"
Link: "absLink" maps to "\\machineB\share"
Modified Path: "\\machineB\share\gamma\file"

सापेक्ष सांकेतिक लिंक का एक उदाहरण

X: C:\alpha\beta\link\gamma\file
Link: "link" maps to "..\..\theta"
Modified Path: "C:\alpha\beta\..\..\theta\gamma\file"
Final Path: "C:\theta\gamma\file"

कड़ी कड़ी

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

विंडोज़ में एक हार्ड लिंक बनाने के लिए, उस लिंक पर जाएँ जहाँ लिंक बनाया जाना है और इस कमांड को दर्ज करें:

mklink /H Link_name target_path

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

• संदर्भ विभिन्न स्थानीय ड्राइव में हैं
• संदर्भों में नेटवर्क ड्राइव शामिल है। दूसरे शब्दों में, संदर्भों में से एक नेटवर्क ड्राइव है
• बनाई जाने वाली कड़ी कड़ी लक्ष्य के समान ही है

संगम

NTFS एक अन्य लिंक प्रकार का समर्थन करता है जिसे जंक्शन कहा जाता है। MSDN इसे निम्नानुसार परिभाषित करता है:

एक जंक्शन (जिसे सॉफ्ट लिंक भी कहा जाता है) एक हार्ड लिंक से अलग होता है जिसमें स्टोरेज ऑब्जेक्ट्स के संदर्भ अलग निर्देशिका होते हैं, और एक जंक्शन एक ही कंप्यूटर पर विभिन्न स्थानीय संस्करणों पर स्थित निर्देशिकाओं को लिंक कर सकता है । अन्यथा, जंक्शन हार्ड लिंक से अनौपचारिक रूप से काम करते हैं।

हार्ड लिंक सेक्शन और जंक्शन सेक्शन में बोल्ड किए गए हिस्से दोनों के बीच बुनियादी अंतर को दर्शाते हैं।

विंडोज़ में एक जंक्शन बनाने के लिए, जहां लिंक बनाना है वहां नेविगेट करें और फिर दर्ज करें:

mklink /J link_name target_path

Answer 13

इसके अलावा:

1. कठिन लिंक का प्रदर्शन प्रतीकात्मक लिंक (माइक्रो-प्रदर्शन) से बेहतर है
2. प्रतीकात्मक लिंक की प्रतिलिपि बनाई जा सकती है, संस्करण-नियंत्रित, ..etc। दूसरे शब्दों में, वे एक वास्तविक फ़ाइल हैं। दूसरे छोर पर, एक हार्ड लिंक कुछ निचले स्तर पर है और आप पाएंगे कि प्रतीकात्मक लिंक की तुलना में, कम उपकरण हैं जो हार्ड लिंक के रूप में हार्ड लिंक के साथ काम करने के लिए साधन प्रदान करते हैं न कि सामान्य फ़ाइलों के रूप में।

Answer 14

बस, हार्ड लिंक: एक फ़ाइल में बस नया नाम जोड़ें, इसका मतलब है, एक फ़ाइल में एक ही समय में कई नाम हो सकते हैं, सभी नाम एक-दूसरे के बराबर हैं, कोई भी पसंदीदा नहीं है, हार्ड लिंक का अर्थ सभी सामग्रियों की प्रतिलिपि बनाने के लिए नहीं है फ़ाइल बनाने और नई फ़ाइल बनाने के लिए ऐसा नहीं है, यह सिर्फ एक वैकल्पिक नाम ज्ञात करने के लिए बनाता है ..

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

Answer 15

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

एक उदाहरण के रूप में, एक फ़ाइल A.txt, एक कठिन लिंक B.txt बनाएँ, और A.txt को हटा दें। जब आपने A.txt बनाया, तो कुछ डेटा बनाया गया था, और एक निर्देशिका प्रविष्टि A.txt। जब आपने हार्ड लिंक बनाया था, तो एक ही निर्देशिका डेटा की ओर इशारा करते हुए एक और निर्देशिका प्रविष्टि B.txt बनाई गई थी। जब आप A.txt को हटाते हैं, तो आपके पास अभी भी सभी डेटा और एक ही निर्देशिका प्रविष्टि B.txt होती है, ठीक उसी तरह जैसे आपने पहली बार में एक फ़ाइल B.txt बनाया था।

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

Answer 16

एक निर्देशिका प्रविष्टि एक लिंक लिंक है:

struct dentry{
    ino_t ino;
    char  name[256];
}

इनो इनोड की संख्या है, नाम फ़ाइल नाम है, इनोड संरचना शायद number जैसी है

struct inode{
      link_t nlink; 
      ...
}

उदाहरण के लिए आप एक फ़ाइल / 1 बनाते हैं, निर्देशिका प्रविष्टि शायद पसंद करें:

struct dentry{
     ino_t ino; /* such as 15 */
     char  name[256]; /* "1" */
} 

इनकोड संरचना शायद जैसे:

   struct inode{ /* inode number 15 */
         link_t nlink; /* nlink = 1 */
         ...
    }

तब आप एक कड़ी बना सकते हैं (100 / हो सकता है), निर्देशिका प्रविष्टि शायद जैसे:

  struct dentry{
     ino_t ino; /* 15 */
     char  name[256]; /* 100 */
  }

इनकोड संरचना शायद जैसे:

   struct inode{ /* inode numebr 15 */
         link_t nlink; /* nlink = 2 */
         ...
    }

फिर आप फ़ाइल 1 के लिए एक प्रतीकात्मक लिंक (हो सकता है / 200) बना सकते हैं, निर्देशिका प्रविष्टि शायद पसंद करें:

  struct dentry{
        ino_t ino; /* such as 16 */
        char  name[256]; /* "200" */
  }

इनकोड संरचना शायद जैसे:

   struct inode{ /* inode number 15 */ 
         link_t nlink; /* nlink = 2 */
         ...
    }

   struct inode{ /* inode number 16 */
         link_t nlink; /* nlink = 1 */
         ...
    } /* the data of inode 16 maybe /1 or 1 */

Answer 17

उपरोक्त सभी उत्तरों को जोड़ने पर हार्डलिंक और सॉफ्टलिंक फ़ाइल को खोजने के अंतर को नीचे समझा जा सकता है:

मेरे पास f6मेरी वर्तमान निर्देशिका में फ़ाइल है, साथ ही एक निर्देशिका भी है t2।

फ़ाइल नाम f1और ./t2/f2प्रतीकात्मक लिंक हैं f6।

फ़ाइल का नाम f7और ./t2/f8हार्ड लिंक हैं f6।

सॉफ्ट और हार्ड लिंक को खोजने के लिए हम इसका उपयोग कर सकते हैं:

$ find -L . -samefile f6 

> ./f1
> ./f6
> ./f7
> ./t2/f2
> ./t2/f8

केवल हार्डलिंक खोजने के लिए हम उपयोग कर सकते हैं:

$ find . -xdev -samefile f6

> ./f6
> ./f7
> ./t2/f8

चूंकि हार्डलिंक को एक ही फाइल सिस्टम पर बनाया जा सकता है, हम एक ही फाइल-सिस्टम / माउंट-पॉइंट में -Lउपयोग किए गए विकल्प (विकल्प के बिना) के सभी हार्डलिंक को खोज सकते हैं -xdev। यह अनावश्यक खोज को विभिन्न आरोह बिंदुओं में सहेजता है।

इसलिए हार्डलिंक खोजना कुछ अधिक तेज़ है, फिर सॉफ्टलिंक खोजना (कृपया सुधार लें कि मैं गलत हूं या स्पष्ट नहीं हूं)।

Answer 18

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

Comments

नहीं। सिम्लिंक "उसी फ़ाइल का दूसरा नाम" नहीं है, यह अपने आप में एक फ़ाइल है, जो लक्ष्य फ़ाइल से लिंक है।

— कुसलानंद १५'१६

Answer 19

उपयोग पर मेरे दो सेंट:

सॉफ्ट लिंक का उपयोग लंबे पथ नामों को छोटा करने के लिए किया जा सकता है, अर्थात:

ln -s /long/folder/name/on/long/path/file.txt /short/file.txt

/short/file.txtमूल फ़ाइल में किए गए परिवर्तन लागू किए जाएंगे।

बड़ी फ़ाइलों को स्थानांतरित करने के लिए हार्ड लिंक का उपयोग किया जा सकता है:

$ ls -lh /myapp/dev/
total 10G
-rw-r--r-- 2 root root 10G May 22 12:09 application.bin

ln /myapp/dev/application.bin /myapp/prd/application.bin

/myapp/devफ़ाइल पर स्पर्श किए बिना , विभिन्न फ़ोल्डर और मूल फ़ाइल की तत्काल प्रतिलिपि (ऑन ) को स्थानांतरित या हटाया जा सकता है/myapp/prd

Answer 20

मुझे बस एक आम परिदृश्य में हार्ड लिंक को समझने का एक आसान तरीका मिला, सॉफ्टवेयर इंस्टॉल।

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

Answer 21

इस उत्तर में जब मैं कहता हूं कि एक फ़ाइल का मतलब है कि स्मृति में स्थान

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

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

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