हार्डलिंक के मामलों का उपयोग करें? [बन्द है]

40

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

filesystems hard-link

— मैथ्यू क्लाइन
स्रोत

4

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

— रिचफ

16

अच्छी तरह से एक फ़ाइल के लिए पहली हार्डलिंक बहुत उपयोगी है।

— हरिकेन मोनिका

@OrangeDog: हाँ, लेकिन आपको इनकोड में लिंक-काउंट फ़ील्ड की आवश्यकता है यदि आप कई लिंक का समर्थन करना चाहते हैं। (आपको अनलंकित लेकिन अभी भी खुले मामले को संभालने के लिए इनोड्स के इन-मेमोरी संस्करण के लिए एक ध्वज की आवश्यकता हो सकती है। बिना जर्नलिंग के एक दुर्घटना के बाद fsck को अभी भी बिना किसी लिंक के इनोड्स की तलाश करनी होगी।)

— पीटर कॉर्डेस

1

POSIX निर्देशिका शब्दार्थ को अलग तरीके से डिजाइन करना होगा: ..हमेशा .मूल निर्देशिका की तरह ही इनोड होता है । चीजों की तरह findदेख सकते हैं कि लिंक गिनती = 2 पत्ती निर्देशिका पता लगाने के लिए, और से बचने के statउप निर्देशिकाओं के लिए देखो करने के लिए readdir से प्रविष्टियां ing। लेकिन यह केवल एक छोटी सी सुविधा है जो गैर-निर्देशिका फ़ाइलों (नियमित, सिमलिंक, डिवाइस, सॉकेट और नाम-पाइप) के हार्डलिंक के लिए समर्थन द्वारा सक्षम है। (हाँ, सिमिलिंक का अपना इनोड है, और इसे हार्डलिंक किया जा सकता है।)

— पीटर कॉर्ड्स

1

हार्डलिंक का उपयोग करने का एक कारण मैंने एसओ की मेरी समीक्षा में "वैश्विक" प्रकृति का नहीं देखा। एक फाइलसिस्टम की कल्पना करें जहाँ फाइलें आम तौर पर छोटी होती हैं (ज्यादातर शॉर्ट मेमो, कहते हैं), लेकिन चीजों को व्यवस्थित रखने के लिए आपको अलग-अलग जगहों पर एक ही फाइल के लिए पॉइंटर्स की आवश्यकता हो सकती है। सीमलिंक के साथ, प्रत्येक पॉइंटर एक इनोड का उपयोग करता है। इस तरह के फाइल सिस्टम में पहले से ही इनोड से बाहर निकलने के साथ एक समस्या हो सकती है। बिंदु के रूप में हार्डलिंक का उपयोग करना इस मुद्दे के साथ मदद करता है। इनोड्स संख्या में सीमित हैं; उनके लिए नाम (कम से कम, उसी तरह नहीं) हैं।

— मैथगुई

27

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

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

ध्यान रखें कि "मूल" और "कॉपी" की अवधारणा हार्ड-लिंक पर लागू नहीं होती है: फ़ाइल का प्रत्येक लिंक एक मूल है, सामान्य अर्थों में "कॉपी" नहीं है। उपयोग-मामले के वर्णन के लिए, हालांकि, शब्द व्यवहार के तर्क की नकल करते हैं।

"मूल" को "कैटलॉग" डायरेक्टरी में सहेजा जाता है, और सॉर्ट की गई "प्रतियां" उन फाइलों से कड़ी-कड़ी होती हैं। सॉर्टिंग निर्देशिकाओं पर फ़ाइल विशेषताएँ r / o पर सेट की जा सकती हैं, फ़ाइल-नामों और सॉर्ट किए गए संरचना में किसी भी आकस्मिक परिवर्तन को रोकते हुए, जबकि कैटलॉग डायरेक्टरी पर विशेषताओं को r / w को आवश्यकतानुसार संशोधित करने की अनुमति दी जा सकती है। (इसके लिए मामला म्यूज़िक फ़ाइल्स होगा, जहां कुछ खिलाड़ी मीडिया इनपुट, या इंटरनेट पुनर्प्राप्ति से मीडिया फ़ाइल में एम्बेड किए गए टैग के आधार पर फ़ाइलों का नाम बदलने और पुनर्गठित करने का प्रयास करते हैं।) इसके अलावा, चूंकि "कॉपी" निर्देशिका की विशेषताओं से भिन्न हो सकते हैं। "मूल" निर्देशिका, सॉर्ट किए गए ढांचे को समूह या दुनिया के लिए उपलब्ध कराया जा सकता है, जबकि प्रतिबंधित एक्सेस मुख्य प्रिंसिपल उपयोगकर्ता के लिए केवल "कैटलॉग" के लिए सुलभ है। पूरी पहुंच के साथ। हालाँकि, फ़ाइलें, हमेशा उस इनोड के सभी लिंक पर समान विशेषताएँ होंगी। (एसीएल को बढ़ाने के लिए पता लगाया जा सकता है, लेकिन मेरा ज्ञान क्षेत्र नहीं।)

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

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

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

— जिप्सी वर्तनी
स्रोत

3

FYI करें: btrfs स्नैपशॉट हार्डलिंक नहीं हैं। उनका अलग व्यवहार होता है (जैसे, एक प्रति को संशोधित करना दूसरे को संशोधित नहीं करता है)। और statकेवल एक लिंक दिखाएगा।

— derobert

@derobert सुनिश्चित नहीं है कि स्नैपशॉट कैसे काम करता है, छोटी जांच दिलचस्प चीजें दिखाती है। अपरिवर्तित फ़ाइलों / निर्देशिकाओं के statलिए एक ही इनकोड संख्या दिखाई देती है, लेकिन अलग-अलग डिवाइस आईडी। सबवोल्यूम जिस तरह से मुख्य रूप से मढ़ा जाता है, शायद ही घुड़सवार, मात्रा के साथ कुछ करना चाहिए। मुझे संदेह है कि यदि मुख्य वॉल्यूम माउंट किया गया था stat, तो फ़ाइल के उस संस्करण को रखने वाले स्नैपशॉट की संख्या के बराबर एक लिंक गणना दिखाएगा। शायद किसी भी अन्य को प्रभावित नहीं करने वाले को संशोधित करने का ख्याल रखता है। हल्के जिज्ञासा पर आधारित अटकलें हैं, लेकिन गहरी खुदाई करने के लिए पर्याप्त उत्सुक नहीं हैं।

— जिप्सी स्पेलवेवर

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

— पीटर कॉर्डेस

23

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

touch a
ln -s a b
rm a

अब bबेकार है। (और ये कदम बहुत अलग हो सकते हैं, विभिन्न लोगों द्वारा किए जा सकते हैं, आदि)

जबकि एक कड़ी के साथ,

touch a
ln a b
rm a

b अभी भी मौजूद है और सही है।

— स्टीफन किट
स्रोत

8

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

— ऑर्केचो

3

@oreshopow मुझे नहीं लगता कि आप अपने बैकअप सिस्टम के पास कहीं भी कड़ी लिंक व्यवहार चाहते हैं। github.com/bit-team/backintime/wiki/… बैकिन्टाइम मूर्खतापूर्ण तरीके से मानता है कि फ़ाइलों में सभी परिवर्तन जगह में अपडेट करने के बजाय एक हटाने-चक्र द्वारा होगा।

— डिप्रेस्डैनियल

10

@DepressedDaniel हार्ड लिंक एक बैकअप सिस्टम के अंदर ठीक हैं , आप नहीं चाहते कि बैकअप लाइव फाइलों से जुड़ा हो। लेकिन किसी भी स्थिति में एक बैकअप को लाइव सिस्टम से सीधे उपलब्ध नहीं होना चाहिए ...

— स्टीफन किट

1

यह एक उत्तर नहीं है - विशेष रूप से, यह उपयोग का मामला नहीं है। यह कठिन लिंक व्यवहार का सिर्फ एक प्रदर्शन है।

— user394

1

@ थॉमसपैड्रॉन-मैकार्थी यह गलतफहमी है। BiT केवल अलग-अलग स्नैपशॉट के अंदर समान फ़ाइलों को लिंक करने के लिए हार्ड-लिंक का उपयोग करता है। वे मूल फ़ाइल से लिंक नहीं हैं! (मैं थोड़ा देव)

— Germar

11

एक एकल प्रोग्राम अपना व्यवहार बदल सकता है जो इस बात पर निर्भर करता है कि इसे किस नाम से लॉन्च किया गया है:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

स्रोत में जो कुछ के माध्यम से तय किया जाता है जैसे

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

हालांकि सटीक विवरण wil में शामिल OS और भाषा के आधार पर भिन्न होता है।

यह (अधिकतर) समान कोड को दो (ज्यादातर) समान बायनेरिज़ के लिए संकलित नहीं करना पड़ता है। डिस्क स्थान सुपर महंगा होने के दिनों में यूनिक्स तारीखों को ध्यान में रखते हुए, हालांकि APUE अध्याय में स्टीवंस के अनुसार हार्डलिंक्स की विभिन्न सीमाओं को बदलने के लिए BSD4.2 (1983) में 4 सिमलिंक लागू किए गए थे। यह जाँचने के लिए एक परीक्षण कार्यक्रम है कि क्या सिम्लिंक नाम का उपयोग किया जाता है क्योंकि प्रोग्राम नाम कुछ इस तरह दिखाई दे सकता है:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

और के माध्यम से परीक्षण किया गया:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$

— thrig
स्रोत

4

लेकिन क्या यह आमतौर पर सॉफ्टलिंक्स के साथ नहीं होता है?

— मैथ्यू क्लाइन

1

@MatthewCline यह आज भी हो सकता है, लेकिन APUE में स्टीवंस के अनुसार 4.2BSD (1983) से पहले सिम्लिंक मौजूद नहीं थे।

— thrig

4

@thrig, प्रश्न विशेष रूप से ऐसे मामलों का उपयोग करने के लिए कहता है, जो सहानुभूति का उपयोग करके पूरा नहीं किया जा सकता है या कम से कम, सहानुभूति का उपयोग करने के बजाय बेहतर है। आपका उत्तर HL और SL दोनों पर लागू होता है।

— मार्सेलो

3

बिजीबॉक्स इसे अधिकतम तक ले जाता है।

— मैक्स राइड

8

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

लाभ:

मैं अभी भी पी 2 पी नेटवर्क में फ़ाइल साझा करता हूं, जैसा कि मुझे rmया mv"कॉपी" भी करना चाहिए ।
फ़ाइल उस पथ पर भी है जहां मुझे इसकी आवश्यकता है; ऐसे अधिकांश स्थानों को साझा नहीं किया जाता है।
मैं rmफ़ाइल को साझा करने से रोकने के लिए "मूल" कर सकता हूं ; यह ऑपरेशन वांछित स्थान पर "कॉपी" को प्रभावित नहीं करता है।
मेरे डिस्कस्पेस का उपयोग केवल एक बार किया जाता है।

मुख्य बिंदु: अगर मुझे पहले से पता था कि मैं कौन सी फाइल rmपहले करूंगा , तो मैं सिमलिंक के साथ जा सकता हूं। लेकिन मुझे कभी पता नहीं चला।

— कामिल मैकियोरोव्स्की
स्रोत

6

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

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

तो यहाँ कुछ उपयोग के मामले हैं जिनमें हार्डलिंक शामिल हैं लेकिन सॉफ्टलिंक नहीं हैं :

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

— मार्सेलो
स्रोत

1

बिंदु 1 के लिए, फाइलों के लिए 'विहित' नाम के रूप में uuids का उपयोग करना, और uuids के सभी मानव-पठनीय नामों को प्रतीकात्मक लिंक बनाना, एक वैकल्पिक समाधान है।

— आर ..

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

— Marcelo

5

बहुत आम, वास्तविक दुनिया का उदाहरण जिसे हार्डलिंक की आवश्यकता है:

git clone --reference <repository>

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

कोई भी रेपो किसी ऑब्जेक्ट को हटा सकता है, लेकिन इनोड बाकी रिपोज के लिए वैध रहता है। और यदि कोई ऑब्जेक्ट सभी रेपो से हटा दिया जाता है, तो उसे डिस्क से हटा दिया जाता है। कड़ी कड़ी खूबसूरती से मजबूत और तेजी से समाधान के लिए बनाते हैं। CI सर्वर में बहुत आम है।

एक गैर-हार्ड-लिंक संस्करण है git clone --shared <repository>:। यह, हालांकि, चंचल है और कई और अधिक चेतावनी है क्योंकि हर कोई एक ही निर्देशिका पर काम कर रहा है।

— पॉल ड्रेपर
स्रोत

4

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

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

हार्डलिंक के बिना यह इतना आसान नहीं होगा।

/ संपादन:

टिप्पणियों के लिए धन्यवाद अब मुझे पता है कि यह करना बेहतर होगा:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

( rmएक अजीब स्थिति से बेहतर ढंग से बचने में सक्षम होने के लिए यहां है, उदाहरण के लिए अगर uImageकुछ अप्रत्याशित है जो mvविफल हो जाएगा [लेकिन जरूरी नहीं कि पिछले ln -sfसमाधान]।)

— phk
स्रोत

2

+1 क्योंकि यह वैचारिक रूप से एक बहुत अच्छा कारण है, लेकिन दुर्भाग्य ln -sfसे परमाणु नहीं है। यह पुराने सीलिंक को हटाता है और एक नया बनाता है। इसे ठीक करने के लिए आपको एक अस्थायी नाम के साथ एक नया सिमलिंक बनाने की आवश्यकता होती है और rename(2)( mv) जिसे आप बदलना चाहते हैं उसके नाम पर।

— आर ..

@ आर .. तुम सही हो! K stat("uImage", {st_mode=S_IFREG|0777, st_size=0, ...}) unlink("uImage"),symlink("backup_image.bin", "uImage")

— phk

1

BTW, install.shकि समस्या का हल के मेरे संस्करण के लिए यहाँ देखें : git.musl-libc.org/cgit/musl/tree/tools/install.sh

— R ..

@ र .. ध्यान दें कि यदि गंतव्य पहले से ही मौजूद है जैसे कि एक सिम्लिंक जो कि एक सिमलिंक लूप का हिस्सा है, तब mvभी -fविफल हो सकता है। डेमो:

ln -sf foo bar; ln -sf bar foo; echo "Before:"; ls -l foo bar; >testfile; mv testfile foo || { echo "Using mv -f"; mv -f testfile foo; }; echo "After:"; ls -l foo bar

— फक

3

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

— थॉमस पडरॉन-मैक्कार्थी
स्रोत

3

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

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

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

इस पद्धति के कुछ नुकसान हैं (मुख्यतः, कि बैकअप स्टोर को दोहराने के लिए फाइलसिस्टम-आधारित टूल का उपयोग करना मुश्किल है), लेकिन यह व्यवहार में काफी मजबूत साबित होता है।

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

उदाहरण: foo.war जावा कोड जो url परोसता है/foo

दुर्भाग्य से, यह निर्णय लेने से पहले सहानुभूति का समाधान करता है।

इसलिए, मान लें कि आप किसी एप्लिकेशन बिल्ड को तैनात करना चाहते हैं, और इसे एक वर्णनात्मक फ़ाइल नाम (जैसे, रिलीज़ नंबर या दिनांक के साथ) दें। आप फ़ाइल को "वास्तविक" नाम के साथ एक सिमलिंक नहीं बना सकते हैं - आपको एक हार्डलिंक बनाना होगा।

foo.warसहानुभूति foo-20170129.warकाम नहीं करती है

foo.warfoo-20170129.warकाम करने के लिए कड़ी मेहनत की ।

मुझे यह टॉमकैट व्यवहार पसंद नहीं है, लेकिन हार्डलिंक मुझे इसके चारों ओर एक रास्ता देता है।

— दान प्रीत
स्रोत