कैसे बताएं कि हार्ड लिंक बनने पर कौन सी फ़ाइल मूल है

Question

उदाहरण के लिए, मेरे पास एक फाइल है myold_file। तो मैं lnएक कड़ी बनाने के लिए उपयोग के रूप में mylink:

ln myold_file mylink

फिर, उपयोग करके भी ls -a, मैं यह नहीं बता सकता कि पुराना कौन सा है।

वैसे भी बताने के लिए है?

Comments

जवाबी कार्रवाई: यदि आप करते हैं ls > a; ln a b; rm a; ln b c, तो कौन सा दूसरे की तुलना में "अधिक मूल" है? aचला गया है, आप के साथ छोड़ दिया जाता है bऔर c...

— glglgl

आप क्या हासिल करने का प्रयास कर रहे हैं? आप क्या हासिल करने का प्रयास कर रहे हैं? ऐसा कोई "मूल" नहीं है। एक फ़ाइल एक मेटा डेटा युक्त इनकोड और डेटा युक्त ब्लॉक का एक संग्रह है। एक निर्देशिका में फ़ाइल का लिंक हो सकता है, और यह लिंक फ़ाइल का नाम और इनोड नंबर है। आप किसी भी फ़ाइल के लिए कई लिंक बना सकते हैं। फ़ाइलें कभी एक लिंक से कम नहीं हो सकती हैं।

— जोहान

इस प्रश्न के स्वीकृत उत्तर की विस्तृत व्याख्या के लिए: उस प्रश्न का स्वीकृत उत्तर देखें ।

— उत्तु

Answer 1

आप नहीं कर सकते, क्योंकि वे वस्तुतः एक ही फ़ाइल हैं, केवल विभिन्न रास्तों से पहुँची हैं। पहले वाले का कोई विशेष दर्जा नहीं है।

Comments

यह स्पष्ट रूप से सही उत्तर है: ओपी का प्रश्न गलतफहमी पर आधारित है।

— डैनियल ईयरविकर

@ अदनान दरअसल, नहीं: दो हार्ड लिंक एक ही फाइल हैं। वे अलग निर्देशिका प्रविष्टियाँ हैं। जेनी डी की शब्दावली सही है।

— गिलेस एसओ- बुराई को रोकना '

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

— आदि

@ जेनीडी और यह बहुत ही एकमात्र तरीका है जो मैंने सुना है "हार्ड लिंक" का उपयोग किया जा रहा है; एक इनसाइड में एक फाइलसिस्टम पॉइंटर। खैर, मुझे लगता है कि हम सभी गलत और सही हैं। मैं इसे व्यर्थ कहकर बहस करना बंद कर दूंगा। आप जवाब दे रहे हैं कि मुझे सही लगता है, आपके पास मुझसे +1 है, और मैं इसे उसी पर छोड़ दूंगा।

— आदि

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

— स्टीव जेसप

Answer 2

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

एक हार्ड लिंक का निर्माण निर्देशिका के लिए एक लिखित ऑपरेशन है जिसमें लिंक शामिल है। इस प्रकार यह निर्देशिका का अद्यतन करता है mtime। तो अगर

1. लिंक विभिन्न निर्देशिकाओं में हैं

2. और आप जानते हैं कि इनमें से कोई भी निर्देशिका नहीं बदली गई है (दूसरी कड़ी लिंक के बनने के बाद फ़ाइल को जोड़ा गया, हटाया गया, नाम बदला गया या फ़ाइल मेटाडेटा बदला गया) तो आप बस mtimeनिर्देशिकाओं की तुलना कर सकते हैं ।

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

यदि लिंक उसी निर्देशिका में हैं (जो आपके प्रश्न में ऐसा प्रतीत होता है) तो यह खराब हो जाता है। तब आप उपयोग कर सकते हैं

ls -lU

आदेशों की एक छाप पाने के लिए जिसमें प्रविष्टियां बनाई गई हैं। यह सही क्रम नहीं होना चाहिए क्योंकि प्रविष्टियाँ हटा दी जा सकती हैं ताकि निर्देशिका प्रविष्टियों के बीच में नई प्रविष्टियाँ बनी हों। और जैसा कि गिल्स ने बताया कि यह नए फाइल सिस्टम के साथ बिल्कुल भी काम नहीं करता है।

Comments

सेलिनक्स, ऑडिट ट्रेल्स, या फाइलसिस्टम जर्नल पर जासूसी का कोई उल्लेख नहीं है ??? एक ऑडिट ट्रेल के बिना मुस्कुराहट , यह जानने का कोई तरीका नहीं है - कुछ और एक गणना अनुमान है

— रिकी बीम

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

— हॉके लैजिंग

अगर हालात सही हैं (जो दुर्लभ है) तो डायरेक्टरी माइम ट्रिक काम करेगी। हालाँकि, जिस तरह से आप इसे प्रस्तुत कर रहे हैं, आप कभी-कभी विपरीत निष्कर्ष पर आएंगे। निर्देशिका माइम केवल एक सार्थक संकेत है यदि यह फ़ाइल के समय के बराबर है। लेकिन ls -lUट्रिक आधुनिक फाइलसिस्टम (ext4, btrfs, zfs) पर काम नहीं करेगी, वहाँ प्रविष्टियाँ सृजन क्रम में बिल्कुल नहीं दिखती हैं।

— गिल्स एसओ- बुराई को रोकना '

@mikeserv - ओपी का प्रश्न गलतफहमी पर आधारित है। यदि वे rm myold_fileतब mylinkभी मौजूद थे और पूरी तरह से काम करेंगे, क्योंकि यह एक समान अंतर्निहित प्रविष्टि का उल्लेख करते हुए समान रूप से अच्छी प्रविष्टि है। केवल जब दोनों को हटा दिया गया है तो सिस्टम इनोड को छोड़ सकता है। एक बार हार्ड लिंकिंग का उपयोग एक ही फाइल के संदर्भ में दो फाइल सिस्टम एंट्रीज बनाने के लिए किया जाता है, वे समकक्ष होते हैं। (ध्यान दें कि "फ़ाइल" का अर्थ है "एक इनोड जो एक फ़ाइल के लिए डेटा रखता है, जैसा कि एक निर्देशिका के विपरीत है)। देखें: en.wikipedia.org/wiki/Inode

— डैनियल ईयरविकेर

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

— कालेब

Answer 3

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

मुझे लगता है कि मैं इस बारे में कुछ नाभि टकटकी लगा रहा हूं कि मुझे यह जानने की आवश्यकता है कि कौन सी निर्देशिका प्रविष्टि पुरानी है और यह जानने की आवश्यकता से कैसे बचें।

Answer 4

मुझे लगता है कि यह प्रश्न (यथोचित) गुमराह करने वाला है कि वास्तव में एक कड़ी क्या है। हालांकि मुझे लगता है कि सबसे सही प्रत्यक्ष उत्तर 'वे दोनों हैं' है ।

यूनिक्स फाइल सिस्टम आम तौर पर वास्तविक फाइल सामग्री और डेटा को आई-नोड्स में संग्रहीत करता है, इन में से कोई भी मार्ग नहीं है, फिर पथ इन i-nodes के लिए एक से कई संबंध रखते हैं। एक सादृश्य व्यक्ति के रूप में लें जो दो नामों बॉब और जो से जाता है। कोई यह नहीं कह सकता कि बॉब जो या पुराने से पुराना है, वे एक ही व्यक्ति के लिए नाम हैं।

यदि आप एक 'मूल' फ़ाइल की अवधारणा को बनाए रखना चाहते हैं और एक नया जिसे आप इसके बजाय एक प्रतीकात्मक लिंक की तलाश कर रहे हैं, तो ये एक उपनाम से अधिक हैं, बस ओएस को एक निर्देश है कि यह एक पथ पर काम करना चाहिए जैसे कि वे नीचे फ़ाइल संरचना को बदलने के बिना दूसरे के लिए थे। (आप इन्हें "ln -s फ़ाइल लिंक" से बना सकते हैं।

Comments

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

— mikeserv

Answer 5

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

एक निर्देशिका के रूप में एक तालिका के बारे में सोचें जो फ़ाइल नामों और इनोड-संख्याओं को सूचीबद्ध करती है।

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

फ़ाइल डिस्क पर ब्लॉक का एक संग्रह है, एक इनोड में संग्रहीत मेटा डेटा द्वारा प्रबंधित और ट्रैक किया गया है। एक फाइल में एक इनोड नंबर होता है।

फ़ाइल नाम के माध्यम से फ़ाइल का डेटा एक्सेस करना एक तीन चरण प्रक्रिया है: फ़ाइल नाम को इनोड नंबर प्राप्त करने के लिए निर्देशिका में देखा जाता है। फिर इनकोड को संबंधित डिस्क ब्लॉक (या ब्लॉक) को खोजने के लिए संदर्भित किया जाता है जिसमें डेटा होता है। फिर अंत में उन ब्लॉक्स को पढ़ा / लिखा जाता है।

तो मूल रूप से यह सब लेने वाला घर है: पहली ("मूल") या बाद में बनाई गई हार्ड लिंक का उपयोग करके फ़ाइल सामग्री तक पहुंचने के बीच बिल्कुल कोई अंतर नहीं है।