क्या किसी सिस्टम में सभी टूटे हुए प्रतीकात्मक लिंक को हटाने के लिए नकारात्मक पक्ष है?


46

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

मैं * निक्स के लिए नया हूँ, लेकिन मुझे फ़ाइलों को लिंक करने के पीछे मुख्य विचार मिलता है और कैसे टूटी हुई लिंक मौजूद हैं। जहाँ तक मुझे पता है, वे गली में कूड़े के बराबर हैं। चीजें जो एक प्रोग्राम मैं हटा रहा हूं, यह बताने के लिए पर्याप्त स्मार्ट नहीं था कि पैकेज मैनेजर मौजूद था, और उसका संबंध था, या ऐसा कुछ जो एक उन्नयन में पीछे रह गया। सबसे पहले, मैंने उस स्क्रिप्ट को ट्विक करना शुरू कर दिया जो मैं उन्हें छोड़ने के लिए चला रहा हूं, फिर मैंने सोचा, 'ठीक है कि हम हमेशा उन्हें हटा सकते हैं जब हम यहां हैं ...

मैं Ubuntu 14.04 (भरोसेमंद तहर) चला रहा हूं । मैं कोई कारण नहीं देख सकता, लेकिन इससे पहले कि मैं आगे बढ़ूं और इसे अपने विकास प्रणाली पर चलाऊं, क्या कोई कारण है कि यह वास्तव में एक भयानक विचार हो सकता है? क्या टूटे हुए सिम्बल कुछ उद्देश्य की पूर्ति करते हैं जिनकी मुझे जानकारी नहीं है?


7
हाँ: टिक जवाब उत्तर देखें। लेकिन इससे भी महत्वपूर्ण बात यह है कि यह आपकी समस्या का समाधान नहीं है: स्क्रिप्ट को ठीक से काम करना है, न कि केवल एक स्वच्छता प्रणाली। एक प्रणाली इसे पवित्र होने के बीच izedmilisecond और लिपि के चलने की दूसरी छमाही के बीच पवित्र किया जा सकता है। इसके अलावा इसने एकल जिम्मेदारी सिद्धांत और यूनिक्स दर्शन का उल्लंघन किया: "एक काम अच्छी तरह से करो"।
15:25 बजे ctrl-alt-delor

जवाबों:


68

टूटे प्रतीकात्मक लिंक के कई कारण हैं:

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

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

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


सहानुभूति (आमतौर पर) उनके मूल निर्देशिका में सम्‍मिलित नहीं है। हालाँकि कुछ फाइल सिस्टम पर लिंक लक्ष्य इनोड में संचित होता है।
जेम्स यंगमैन

बहुत अच्छी सूची है। मेरे पास लिंक का एक गुच्छा है जो 4 और 6 दोनों प्रकारों में आते हैं। वे एक फाइल सिस्टम में इंगित करते हैं जिसे मैं SSHFS के साथ माउंट करता हूं। जब फाइलसिस्टम माउंट नहीं होता है, तो वे टाइप 4 होते हैं; जब फाइलसिस्टम आरोहित होता है, केवल मैं ही इसे एक्सेस कर सकता हूं, इसलिए वे अन्य सभी (यहां तक ​​कि रूट) के लिए टाइप 6 हैं।
बमर

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

काफी व्यापक जवाब!
njzk2

1
@MichaelDurrant उह? मुद्दा यह है कि नकारात्मक पक्ष (या इसके अभाव) इस बात पर निर्भर करता है कि टूटी हुई सिम्कलिन कैसे हुई।
गिल्स एसओ- बुराई को रोकना '

19

सभी झूलने वाले प्रतीकात्मक लिंक को आँख बंद करके न निकालें। वे बस कुछ जानकारी ले जाने के लिए मौजूद हो सकते हैं, और सामान्य फ़ाइलों की तुलना में अधिक सुरक्षित हो सकते हैं क्योंकि एक सिमलिंक निर्माण परमाणु है।

उदाहरण के लिए, फ़ायरफ़ॉक्स एक लॉकफ़ाइल "लॉक" बनाता है जो एक सिम्लिंक है जिसका मूल्य "IP_address: + PID" जैसा है।


1
तो जैसे, एक प्रोग्राम एक खाली फ़ाइल को गतिशील रूप से पॉप्युलेट कर सकता है कि इनमें से कोई भी सहानुभूति एक टूटी हुई कड़ी है, जबकि प्रोग्राम नहीं चल रहा है ? या यह सिर्फ जानकारी का एक टुकड़ा हो सकता है?
कंबल_कट

1
@knotech कुछ सहानुभूति का उद्देश्य (जरूरी नहीं कि एक चल रहे कार्यक्रम से जुड़ा हो) केवल अस्तित्व के लिए हो सकता है। उनका मूल्य या तो अर्थहीन है या किसी विशेष जानकारी को बताता है; दोनों मामलों में, सामान्य रूप से, वे कुछ भी नहीं करने के लिए इशारा करते हैं। कोई खाली फ़ाइल नहीं है, बस एक सिम्लिंक है। : यह भी ध्यान रखें, एक उदाहरण के रूप, जीसीसी के मामले बनाता है, "टिकट बिट" खुद की तरफ निर्देशित सिमलिंक बनाने जो gcc.gnu.org/ml/libstdc++/2011-02/msg00014.html
vinc17

6

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

उदाहरण के लिए, वर्चुअल होस्ट केवल निर्देशिका हैं, और एक नया वर्चुअल होस्ट बनाना उतना ही सरल है

mkdir www.example.com:80

कॉन्फ़िगर करने के लिए कौन सी फाइलें सेवा के लिए?

chmod o+r file_that_should_be_served
chmod o-r secret_passwords

सीजीआई के रूप में निष्पादित करने के लिए कौन सी फाइलें कॉन्फ़िगर करें और कौन सी सेवा करें?

chmod a-x plain_file.html
chmod a+x cgi_script.html

और अंत में (और इस प्रश्न के लिए प्रासंगिक): एक रीडायरेक्ट को कॉन्फ़िगर करना?

ln -s 'http://www.google.com/?q=awesome+query+site:www.example.com' search.html

अब आपके पास एक सिमलिंक होगा search.html, जो कि कहीं भी इंगित करेगा, लेकिन यह आपकी साइट के काम के लिए महत्वपूर्ण है।


0

एक सिम्लिंक एक विशेष फ़ाइल सिस्टम स्थान या नाम पर निर्माण के लिए बाध्य करने के लिए अभी तक एक एम्टी स्थान को इंगित कर सकता है।

तो नहीं - उन्हें आँख बंद करके न निकालें।


0

बासी प्रतीकात्मक लिंक को हटाने के लिए एक महत्वपूर्ण नकारात्मक पक्ष यह है कि आप उस संदर्भ को खो देते हैं जहां वे इंगित करते थे, जो काफी मूल्यवान हो सकता है!

मान लें कि मेरे पास " send_to" नामक एक फ़ाइल के लिए एक प्रतीकात्मक लिंक है जो इंगित करता है /Users/myname/tmpऔर लगता है कि /Users/myname/tmpमौजूद नहीं है।

प्रतीकात्मक लिंक के साथ मुझे पता है कि फ़ाइल कहाँ होने का इरादा था । उदाहरण के लिए, इस मामले में मैं देख सकता हूं कि यह एक अस्थायी निर्देशिका है और अगर मुझे इसे "ठीक" करने की आवश्यकता है, तो मुझे अस्थायी निर्देशिका को गंतव्य के रूप में समझना चाहिए।

इसी तरह एक लिंक " my_config" जो उस ओर इशारा करता /etc/conf_fileहै वह 'खराब' हो जाता है क्योंकि conf_fileनाम बदलकर पुष्टिकरण_फाइल कर दिया जाता है। यदि आप /etcनिर्देशिका में गए थे और एक किया था lsऔर देखा कि नामक फ़ाइल conf_fileगायब थी, लेकिन confirmation_fileक्या आपके पास अब लिंक को ठीक करने के लिए पर्याप्त जानकारी हो सकती है।


-2

लिनक्स कमांड लाइन से उद्धृत करना (लिनक्स के नए शौक के लिए सबसे अच्छी पुस्तक, और आप इसे मुफ्त में यहां से डाउनलोड कर सकते हैं ):

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

यहाँ वह जगह है जहाँ प्रतीकात्मक लिंक दिन बचाते हैं। मान लें कि हम "फू" का संस्करण 2.6 स्थापित करते हैं, जिसका फ़ाइल नाम "फू-2.6" है और फिर "फू" नामक एक प्रतीकात्मक लिंक बनाएं जो "फू-2.6" की ओर इशारा करता है। इसका मतलब है कि जब कोई प्रोग्राम फ़ाइल को खोलता है। foo ”, यह वास्तव में“ foo-2.6 ”फाइल खोल रहा है। अब हर कोई खुश है। "फू" पर भरोसा करने वाले कार्यक्रम इसे पा सकते हैं और हम अभी भी देख सकते हैं कि वास्तविक संस्करण क्या स्थापित है। जब "foo-2.7" को अपग्रेड करने का समय आता है, तो हम सिर्फ फाइल को अपने सिस्टम में जोड़ते हैं, प्रतीकात्मक लिंक "फू" को हटाते हैं और एक नया बनाते हैं जो नए संस्करण को इंगित करता है। यह न केवल संस्करण के उन्नयन की समस्या को हल करता है, बल्कि यह हमें हमारे मशीन पर दोनों संस्करणों को रखने की भी अनुमति देता है। कल्पना कीजिए कि "foo-2.7" में एक बग है (उन डेवलपर्स को लानत है!) और हमें पुराने संस्करण को वापस करने की आवश्यकता है। फिर,

तो नहीं, मैं प्रतीकात्मक लिंक नहीं हटाऊंगा क्योंकि यह निश्चित रूप से एक सिरदर्द बन जाएगा, और आप अपने सिस्टम को गंभीर रूप से गड़बड़ करने का जोखिम उठाते हैं।


6
ओपी सिम्बलिंक टाउट कोर्ट को हटाने की वकालत नहीं कर रहा था - केवल टूटी हुई सिम्लिंक्स, यानी सिमलिंक जो किसी भी मौजूदा मौजूदा फ़ाइल की ओर इशारा नहीं करती हैं।
एलसर्नी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.