मेरे पास उदाहरण Minecraft है। लिनक्स पर बुककिट चलाते समय मैं / प्लग इन फ़ोल्डर में .jar फ़ाइलों को हटा या अपडेट कर सकता हूं और बस 'पुनः लोड' कमांड चला सकता हूं।
विंडोज में, मुझे पूरी सर्वर प्रक्रिया को नीचे ले जाना होगा क्योंकि यह शिकायत करेगा कि .jar फ़ाइल वर्तमान में उपयोग में है जब मैं इसे हटाने या बदलने का प्रयास करता हूं।
यह मेरे लिए बहुत बढ़िया है, लेकिन ऐसा क्यों होता है? यहाँ लिनक्स अलग क्या कर रहा है?
जवाबों:
लिनक्स विंडोज की तरह से एक फ़ाइल को पूरी तरह से अलग करता है। सबसे पहले, फ़ाइलों को * यूनिक्स देशी फाइल सिस्टम में कैसे प्रबंधित किया जाता है पर एक संक्षिप्त विवरण।
फाइल को मल्टीलेवल स्ट्रक्चर में डिस्क पर रखा जाता है i-node। प्रत्येक आई-नोड में एकल फाइलसिस्टम पर एक अद्वितीय संख्या है। आई-नोड संरचना एक फ़ाइल के बारे में अलग-अलग जानकारी रखती है, जैसे उसका आकार, फ़ाइल के लिए आवंटित डेटा ब्लॉक आदि, लेकिन इस उत्तर के लिए सबसे महत्वपूर्ण डेटा तत्व एक है link counter। directoriesफ़ाइलें जो फ़ाइलों के बारे में रिकॉर्ड रखने के हैं। प्रत्येक रिकॉर्ड में आई-नोड संख्या है जो इसे संदर्भित करता है, फ़ाइल नाम की लंबाई और फ़ाइल नाम ही। यह स्कीम एक व्यक्ति को 'पॉइंटर्स' यानी 'लिंक' को अलग-अलग जगहों पर अलग-अलग नामों से रखने की अनुमति देती है। आई-नोड का लिंक काउंटर वास्तव में इस आई-नोड को संदर्भित करने वाले लिंक की संख्या रखता है।
जब कोई प्रक्रिया फ़ाइल को खोलती है तो क्या होता है? पहले open()फ़ंक्शन फ़ाइल रिकॉर्ड की खोज करता है। फिर यह जांचता है कि क्या इस आई-नोड के लिए इन-मेमोरी आई-नोड संरचना पहले से मौजूद है। ऐसा हो सकता है यदि कुछ एप्लिकेशन में यह फ़ाइल पहले से ही थी। अन्यथा, सिस्टम एक नई इन-मेमोरी आई-नोड संरचना को इनिशियलाइज़ करता है। तब सिस्टम इन-मेमोरी आई-नोड संरचना ओपन काउंटर को बढ़ाता है और एप्लिकेशन पर इसकी फाइल डिस्क्रिप्टर पर लौटता है।
किसी फ़ाइल को हटाने के लिए लिनक्स लाइब्रेरी कॉल को कहा जाता है unlink। यह फ़ंक्शन एक निर्देशिका से फ़ाइल रिकॉर्ड को हटाता है और i-नोड के लिंक काउंटर को घटाता है। यदि सिस्टम ने पाया कि एक इन-मेमोरी आई-नोड संरचना मौजूद है और इसका खुला काउंटर शून्य नहीं है, तो यह कॉल एप्लिकेशन पर नियंत्रण लौटाता है। अन्यथा यह जांचता है कि क्या लिंक-काउंटर शून्य हो गया और यदि ऐसा होता है तो सिस्टम आई-नोड और आई-नोड के लिए आवंटित सभी ब्लॉक को मुक्त कर देता है और आवेदन पर वापस आ जाता है।
क्या होता है कि कोई एप्लिकेशन फ़ाइल बंद कर देती है? फ़ंक्शन close()ओपन काउंटर को घटाता है और इसके मूल्य की जांच करता है। यदि मान गैर-शून्य है, तो फ़ंक्शन अनुप्रयोग में वापस आ जाता है। अन्यथा यह जांचता है कि क्या आई-नोड लिंक काउंटर शून्य है। यदि यह शून्य है, तो यह एप्लिकेशन पर लौटने से पहले फ़ाइल के सभी ब्लॉकों और आई-नोड को मुक्त कर देता है।
यह तंत्र आपको फ़ाइल खोलने के दौरान "हटाने" की अनुमति देता है। उसी समय एक फ़ाइल खोलने वाले एप्लिकेशन में अभी भी फ़ाइल में डेटा तक पहुंच है। तो, JRE, आपके उदाहरण में, अभी भी फ़ाइल का अपना संस्करण खोला हुआ है, जबकि डिस्क पर एक और अद्यतन संस्करण है।
अधिक से अधिक, यह सुविधा आपको ग्लिबेक (libc) - सभी अनुप्रयोगों के मूल पुस्तकालय को अद्यतन करने की अनुमति देती है - आपके सिस्टम में इसके सामान्य संचालन को बाधित किए बिना।
20 साल पहले हमें डॉस के तहत एफएटी के अलावा किसी अन्य फाइल सिस्टम का पता नहीं था। इस फाइल सिस्टम में एक अलग संरचना और प्रबंधन सिद्धांत हैं। ये सिद्धांत खोलने पर आपको एक फ़ाइल को हटाने की अनुमति नहीं देते हैं, इसलिए डॉस और हाल ही में विंडोज को खुली हुई फ़ाइल पर किसी भी डिलीट अनुरोध को अस्वीकार करना पड़ता है। संभवतः NTFS * nix फाइल सिस्टम के समान व्यवहार की अनुमति देगा लेकिन Microsoft ने फ़ाइल विलोपन के अभ्यस्त व्यवहार को बनाए रखने का निर्णय लिया।
यह उत्तर है। छोटा नहीं है, लेकिन अब आपके पास विचार है।
संपादित करें : Win32गंदगी के स्रोतों पर एक अच्छा पढ़ा : https://blogs.msdn.microsoft.com/oldnewthing/20040607-00/?p=38993
क्रेडिट @Jon
ren MonsterB.jar MonsterB.ja_- यह काम करना चाहिए। यह निश्चित रूप से dll और exe फ़ाइलों के लिए काम करता है।
fopenकमांड ध्वज के CreateFileसाथ कहता है FILE_SHARE_DELETE, इसलिए यह फाइलों को खोलने वाले अधिकांश कार्यक्रमों के लिए इसे अस्वीकार कर देता है।