उबंटू में एक रनिंग प्रोग्राम को स्थानांतरित करना क्यों संभव है?

24

मुझे बस एहसास हुआ कि मैं एक सक्रिय सक्रिय कार्यक्रम को एक अलग निर्देशिका में स्थानांतरित करने में सक्षम हूं। मेरे अनुभव में जो कि MacOs या Windows में संभव नहीं था। यह उबंटू में कैसे काम करता है?

संपादित करें: मैंने सोचा कि यह मैक पर संभव नहीं था, लेकिन जाहिरा तौर पर यह संभव है क्योंकि टिप्पणियां सत्यापित करती हैं। यह केवल विंडोज पर संभव नहीं है। सभी उत्तरों के लिए धन्यवाद।

kernel files directory

— n0.ob
स्रोत

2

बहुत ज्यादा एक क्रॉस-साइट डुबकी: stackoverflow.com/a/196910/1394393 ।

— jpmc26

1

आप rename(2)ओएस एक्स पर एक निष्पादन योग्य नहीं चल सकते हैं ? क्या होता है, आपको मिलता है EBUSYया कुछ और? यह काम क्यों नहीं करता है? नाम (2) मैन पेज ETXTBUSYउस सिस्टम कॉल के लिए दस्तावेज नहीं करता है , और केवल EBUSYनिर्देशिका नाम बदलने के लिए संभव होने के बारे में बात करता है , इसलिए मुझे पता नहीं था कि एक पॉसिक्स सिस्टम भी नामकरण निष्पादनयोग्य को अस्वीकार कर सकता है।

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

3

macOS एप्स को चलते हुए भी ले जाया जा सकता है, सिर्फ ट्रैश नहीं किया गया है। मुझे लगता है कि उसके बाद कुछ एप्लिकेशन गलत हो सकते हैं, उदाहरण के लिए, यदि वे NSBundle et al के माध्यम से ऐसे URL को जनरेट करने के बजाय उनके बाइनरी या बंडल किए गए संसाधनों को फ़ाइल URL स्टोर करते हैं। मुझे शक है कि यह macOS 'POSIX अनुपालन है।

— कांस्टेंटिनो त्सारोहस

1

यह वास्तव में लिनक्स के रूप में काम करता है, आपको पता होना चाहिए कि आप क्या कर रहे हैं। : P

— userDepth

2

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

— थॉमस

32

मुझे इसे तोड़ने दो।

जब आप एक निष्पादन योग्य चलाते हैं, तो सिस्टम कॉल का एक क्रम निष्पादित होता है, सबसे विशेष रूप से fork()और execve():

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

इस बिंदु पर, कर्नेल के ईएलएफ लोडर ने निष्पादन योग्य के पाठ और डेटा खंडों को मेमोरी में मैप किया है, जैसे कि उसने mmap()सिस्टम कॉल का उपयोग किया था (क्रमशः रीड-ओनली और प्राइवेट रीड-राइट मैपिंग के साथ)। BSS को मैप भी किया जाता है जैसे कि MAP_ANONYMOUS के साथ। (BTW, मैं यहाँ सादगी के लिए डायनेमिक लिंकिंग को नज़रअंदाज़ कर रहा हूँ: डायनामिक लिंकर open()s और mmap()s सभी डायनेमिक लाइब्रेरी मुख्य निष्पादन योग्य प्रविष्टि बिंदु पर कूदने से पहले।)

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

निष्पादन योग्य फ़ाइल को निचले स्तर पर इनोड द्वारा पहचाना जाता है। फ़ाइल को निष्पादित किया जाना शुरू होने के बाद, कर्नेल इनकोड संदर्भ द्वारा फ़ाइल सामग्री को अक्षुण्ण रखता है, फ़ाइल नाम से नहीं, जैसे कि ओपन फ़ाइल डिस्क्रिप्टर या फ़ाइल-समर्थित मेमोरी मैपिंग के लिए। तो आप आसानी से फाइल सिस्टम के किसी अन्य स्थान पर या एक अलग फाइल सिस्टम पर भी निष्पादन योग्य स्थानांतरित कर सकते हैं। साइड नोट के रूप में, प्रक्रिया के विभिन्न स्टेट को जांचने के लिए आप /proc/PID(पीआईडी दी गई प्रक्रिया की प्रोसेस आईडी है) डायरेक्टरी में जा सकते हैं। आप निष्पादन योग्य फ़ाइल को भी खोल सकते हैं /proc/PID/exe, यहां तक कि यह डिस्क से अनलिंक किया गया है।

अब चलते चलते खुदाई करते हैं:

जब आप किसी फ़ाइल को एक ही फाइल सिस्टम में स्थानांतरित करते हैं, तो सिस्टम कॉल जो निष्पादित होता है rename(), जो फ़ाइल को किसी अन्य नाम में बदल देता है, फ़ाइल का इनोड वही रहता है।

जबकि दो अलग-अलग फाइल सिस्टम के बीच दो चीजें होती हैं:

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

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

अब मज़े के लिए, कल्पना कीजिए कि जब आप दो फाइलमाइट्स के बीच फ़ाइलों को स्थानांतरित कर रहे हैं तो क्या होता है और आपके पास unlink()स्रोत से फ़ाइल की अनुमति नहीं है ?

ठीक है, फ़ाइल को पहले गंतव्य पर कॉपी किया जाएगा ( ) read(), write()और फिर unlink()अपर्याप्त अनुमति के कारण विफल हो जाएगा। तो, फाइल दोनों फाइल सिस्टम में रहेगी !!

— heemayl
स्रोत

5

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

— jlliagre

@jlliagre संपादित, मुझे आशा है कि अब यह स्पष्ट हो जाएगा। धन्यवाद।

— हेमायल

6

"प्रक्रिया अब फ़ाइल सिस्टम का उपयोग नहीं कर रही है" कथन अभी भी संदिग्ध है।

— 8

2

बुनियादी समझ जो फ़ाइल सिस्टम में किसी फ़ाइल को सीधे फ़ाइल नाम से पहचानी नहीं जाती है, वह बहुत स्पष्ट होनी चाहिए।

— Thorbjørn Ravn Andersen

2

आपके अपडेट में अभी भी अशुद्धियाँ हैं। mmapऔर unmapसिस्टम कॉल लोड करने के लिए इस्तेमाल किया और मांग पर पृष्ठों उतारना, पृष्ठों कर्नेल द्वारा लोड किए गए हैं जब तक पहुँचने के लिए उन्हें एक पृष्ठ दोष उत्पन्न करते हैं, पृष्ठों स्मृति से उतार कर रहे हैं जब ओएस का मानना है रैम बेहतर कुछ और के लिए इस्तेमाल किया जाएगा नहीं कर रहे हैं। इन लोड / अनलोड संचालन में कोई सिस्टम कॉल शामिल नहीं है।

— 21

14

खैर, यह बहुत straighforward है। चलो एक निष्पादन योग्य नाम / usr / स्थानीय / बिन / whoopdeedoo लेते हैं। यह केवल तथाकथित इनोड का संदर्भ है (यूनिक्स फाइलसिस्टम पर फाइलों की मूल संरचना)। यह "उपयोग में" चिह्नित होने वाला इनोड है।

अब जब आप फ़ाइल / usr / स्थानीय / whoopdeedoo को हटाते हैं या स्थानांतरित करते हैं, तो केवल एक चीज जिसे स्थानांतरित किया जाता है (या मिटा दिया जाता है), इनोड का संदर्भ है। इनकोड ही अपरिवर्तित रहता है। वह मूल रूप से यह है।

मुझे इसे सत्यापित करना चाहिए, लेकिन मेरा मानना है कि आप मैक ओएस एक्स फाइलसिस्टम पर भी ऐसा कर सकते हैं।

विंडोज एक अलग दृष्टिकोण लेता है। क्यूं कर? कौन जाने...? मैं NTFS के इंटर्न से परिचित नहीं हूं। सैद्धांतिक रूप से, सभी फाइल सिस्टम जो फाइलनाम के लिए आंतरिक संरचनाओं के संदर्भ का उपयोग करते हैं, उन्हें ऐसा करने में सक्षम होना चाहिए।

मैं स्वीकार करता हूं, मैंने सरलीकरण किया, लेकिन विकिपीडिया पर "इम्प्लीकेशन्स" खंड को पढ़ा, जो मेरे से बहुत बेहतर काम करता है।

— jawtheshark
स्रोत

1

यदि आप निष्पादन योग्य शुरू करने के लिए विंडोज में शॉर्टकट का उपयोग करते हैं, तो आप शॉर्टकट को भी मिटा सकते हैं, यदि आप इसकी तुलना करना चाहते हैं, तो हो सकता है? = 3

— रे

2

नहीं, यह एक प्रतीकात्मक लिंक को पोंछने जैसा होगा। कहीं अन्य टिप्पणियों में, यह कहा गया है कि व्यवहार FAT फ़ाइल सिस्टम के साथ विरासत समर्थन के कारण है। यह एक संभावित कारण की तरह लगता है।

— जवथेशकर

1

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

— रुस्लान

13

एक बात जो अन्य सभी उत्तरों से गायब लगती है, वह यह है: एक बार एक फाइल खोले जाने के बाद और एक प्रोग्राम एक ओपन फाइल डिस्क्रिप्टर रखता है, फाइल को सिस्टम से तब तक नहीं हटाया जाएगा, जब तक कि फाइल डिस्क्रिप्टर बंद न हो जाए।

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

इसके अलावा जब कर्नेल किसी फ़ाइल को निष्पादित करता है तो यह निष्पादन योग्य फ़ाइल के लिए एक संदर्भ रखता है और यह फिर से निष्पादन के दौरान इसके किसी भी संशोधन को रोक देगा।

तो अंत में भले ही यह की तरह लग रहा है जिसे आप हटाना / फ़ाइलें है कि एक चल रहे प्रोग्राम को बनाने, वास्तव में उन फ़ाइलों की सामग्री स्मृति में रखा जाता है ले जाने के लिए जब तक कार्यक्रम समाप्त होता है में सक्षम हैं।

— Bakuriu
स्रोत

1

यह सही नहीं है। execve()किसी भी एफडी को वापस नहीं करता है, यह बस प्रोग्राम को निष्पादित करता है। उदाहरण के लिए, यदि आप दौड़ते हैं tail -f /foo.logतो उनकी एफडी ( /proc/PID/fd/<fd_num>) के लिए संबद्ध tailहै, foo.logलेकिन निष्पादन योग्य के लिए ही tailनहीं, अपने माता-पिता पर भी। यह एकल निष्पादकों के लिए भी सही है।

— heemayl

@heemayl मैंने उल्लेख नहीं किया execveइसलिए मैं यह नहीं देखता कि यह कैसे प्रासंगिक है। एक बार जब कर्नेल किसी फ़ाइल को निष्पादित करना शुरू कर देता है, तो फ़ाइल को बदलने की कोशिश करने से उस प्रोग्राम को संशोधित नहीं किया जाएगा जो कर्नेल को प्वाइंट म्यूट को लोड करने के लिए जा रहा है। यदि आप इसे चलाने के दौरान निष्पादन योग्य "अपडेट" करना चाहते हैं, तो आप execveकर्नेल को फ़ाइल को फिर से पढ़ने के लिए किसी बिंदु पर कॉल कर सकते हैं , लेकिन मैं यह नहीं देखता कि यह कैसे मायने रखता है। मुद्दा यह है: "चल रहे निष्पादन योग्य" को हटाना वास्तव में किसी भी डेटा को हटाने से ट्रिगर नहीं करता है जब तक कि निष्पादन योग्य बंद नहीं हो जाता है।

— बकुरीउ

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

— heemayl

2

फ़ाइल का संदर्भ देने के लिए आपको फ़ाइल हैंडल की आवश्यकता नहीं है - मैप किए गए पृष्ठ भी पर्याप्त हैं।

— साइमन रिक्टर

1

यूनिक्स में "फाइल हैंडल" नहीं है। open()एक फाइल डिस्क्रिप्टर लौटाता है , जिसके बारे में हेमायल यहां बात कर रहे हैं execve()। हां, एक चल रही प्रक्रिया में इसके निष्पादन योग्य का संदर्भ होता है, लेकिन यह एक फ़ाइल विवरणक नहीं है। संभवत: यदि यह munmap()अपने निष्पादन के सभी मानचित्रणों को संपादित करता है, तब भी इसका एक संदर्भ (/ proc / self / exe में प्रतिबिंबित) होगा जिसने इनोड को मुक्त होने से रोक दिया था। (यह दुर्घटनाग्रस्त बिना संभव होगा यदि यह एक लाइब्रेरी फ़ंक्शन से किया गया था जो कभी नहीं लौटा।) BTW, ट्रंकिंग या एक इन-इम्प्लीमेंटेबल निष्पादन को संशोधित कर सकता है जो आपको दे सकता है ETXTBUSY, लेकिन काम कर सकता है।

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

7

लिनक्स फाइल सिस्टम में, जब आप किसी फाइल को स्थानांतरित करते हैं, तो जब तक वह फाइल सिस्टम की सीमाओं को पार नहीं करता है (पढ़ें: एक ही डिस्क / विभाजन पर रहता है) जो आप बदल रहे हैं ..वह नए स्थान के लिए (मूल निर्देशिका) का इनोड है। । वास्तविक डेटा डिस्क पर बिल्कुल भी स्थानांतरित नहीं हुआ है, बस पॉइंटर ताकि फाइल सिस्टम को पता हो कि उसे कहां खोजना है।

यही कारण है कि कदम संचालन इतनी जल्दी और संभावना है कि क्यों कोई मुद्दा नहीं चल रहा है कार्यक्रम चल रहा है क्योंकि आप वास्तव में कार्यक्रम को ही नहीं चला रहे हैं।

— I_GNU_it_all_along
स्रोत

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

— jlliagre

6

यह संभव है क्योंकि किसी प्रोग्राम को ले जाने से इसे लॉन्च करने से शुरू होने वाली रनिंग प्रक्रिया प्रभावित नहीं होती है।

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

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

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

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

— jlliagre
स्रोत

1

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

— थोरबजोरन रावन एंडरसन

@ ThorbjørnRavnAndersen मुझे आश्चर्य है कि क्यों सभी अपडेट अभी भी पुनरारंभ की आवश्यकता है :(

— Braiam

1

@Braiam वे नहीं करते। करीब से देखना है। भले ही बायनेरिज़ को अपडेट किया जा सकता है लेकिन कर्नेल को (मेरी जानकारी के लिए) नहीं किया जा सकता है और रिबूट की आवश्यकता होती है जिसे एक नए संस्करण के साथ प्रतिस्थापित किया जा सकता है। यह अधिकांश ऑपरेटिंग सिस्टम गुठली के लिए मान्य है। लाइनर लोगों को मैंने लिनक्स के लिए kpatch लिखा है जो एक लिनक्स कर्नेल को चलाने के दौरान पैच कर सकता है - en.wikipedia.org/wiki/Kpatch

— Thorbjørn Ravn Andersen देखें

@ ThorbjørnRavnAndersen मेरा मतलब है "सभी विंडोज़ अपडेट"

— Braiam

@Braiam हाँ - तो मैंने किया। कृपया एक करीब देखो।

— थोर्बोजर्न रेवन एंडरसन

4

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

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

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

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

— user584745
स्रोत