मैंने देखा कि जब फ़ाइल (.exe या .dll) पर फ़ाइल निष्पादित की जाती है, तो इसे लॉक किया जाता है और हटाया जा सकता है, स्थानांतरित या संशोधित नहीं किया जा सकता है।निष्पादन फ़ाइलों को लॉक करना: विंडोज करता है, लिनक्स नहीं करता है। क्यूं कर?
दूसरी ओर, लिनक्स निष्पादन फ़ाइलों को लॉक नहीं करता है और उन्हें हटा, स्थानांतरित या संशोधित कर सकता है।
लिनक्स नहीं होने पर विंडोज लॉक क्यों करता है? लॉक करने का कोई फायदा है?
मुझे लगता है कि लिनक्स/यूनिक्स एक ही लॉकिंग यांत्रिकी का उपयोग नहीं करता है क्योंकि वे एक बहु-उपयोगकर्ता प्रणाली के रूप में जमीन से बने होते हैं - जो एक ही फ़ाइल का उपयोग कर एकाधिक उपयोगकर्ताओं की संभावना की अपेक्षा करेगा, शायद विभिन्न उद्देश्यों के लिए भी ।
क्या लॉक करने का कोई फायदा है? खैर, यह संभवतः ओएस को प्रबंधित करने वाले पॉइंटर्स की मात्रा को कम कर सकता है, लेकिन अब एक दिन बचत की मात्रा बहुत नगण्य है। लॉकिंग के बारे में सोचने का सबसे बड़ा फायदा यह है: आप कुछ उपयोगकर्ता-देखने योग्य अस्पष्टता को बचाते हैं। यदि उपयोगकर्ता एक बाइनरी फ़ाइल चला रहा है, और उपयोगकर्ता बी इसे हटा देता है, तो वास्तविक फ़ाइल को तब तक चिपकना पड़ता है जब तक उपयोगकर्ता ए की प्रक्रिया पूरी नहीं हो जाती। फिर भी, यदि उपयोगकर्ता बी या कोई अन्य उपयोगकर्ता इसके लिए फ़ाइल सिस्टम को देखता है, तो वे इसे नहीं ढूंढ पाएंगे - लेकिन यह स्थान लेना जारी रखेगा। वास्तव में मेरे लिए एक बड़ी चिंता नहीं है।
मुझे लगता है कि यह काफी हद तक खिड़की के फाइल सिस्टम के साथ पिछड़ा संगतता पर एक प्रश्न है।
"विंडोज़" विंडोज एनटी लाइन है। यह एकल उपयोगकर्ता विंडोज 3.11 के लिए बहु-उपयोगकर्ता उत्तराधिकारी के रूप में डिज़ाइन किया गया था। यूनिक्स की तुलना करें, जो मल्टीक्स के एकल उपयोगकर्ता उत्तराधिकारी हैं। – MSalters
लिनक्स में संदर्भ-गणना तंत्र है, इसलिए आप इसे निष्पादित करते समय फ़ाइल को हटा सकते हैं, और यह तब तक जारी रहेगा जब तक कि कुछ प्रक्रिया (जिसे पहले इसे खोला गया था) के लिए एक खुला संभाल है। जब आप इसे हटाते हैं तो फ़ाइल के लिए निर्देशिका प्रविष्टि हटा दी जाती है, इसलिए इसे और खोला नहीं जा सकता है, लेकिन पहले से ही इस फ़ाइल का उपयोग करने वाली प्रक्रियाएं इसका उपयोग कर सकती हैं। एक बार इस फ़ाइल का उपयोग करने वाली सभी प्रक्रियाएं समाप्त हो जाने पर, फ़ाइल स्वचालित रूप से हटा दी जाती है।
विंडोज़ में यह क्षमता नहीं है, इसलिए इसे तब तक लॉक करने के लिए मजबूर किया जाता है जब तक कि इसे निष्पादित करने वाली सभी प्रक्रियाएं समाप्त नहीं हो जातीं।
मेरा मानना है कि लिनक्स व्यवहार बेहतर है। शायद कुछ गहरे वास्तुशिल्प कारण हैं, लेकिन मुझे सबसे अधिक आकर्षक लगता है कि प्रमुख (और सरल) कारण यह है कि विंडोज़ में, आप कभी-कभी फ़ाइल को हटा नहीं सकते हैं, आपको पता नहीं है कि क्यों, और आपको पता है कि कुछ प्रक्रिया इसे रख रही है उपयोग। लिनक्स में यह कभी नहीं होता है।
जहाँ तक मुझे पता है, लिनक्स लॉक निष्पादन योग्य हैं जब वे चल रहे हैं - हालांकि, यह inode लॉक करता है। इसका मतलब है कि आप "फ़ाइल" को हटा सकते हैं लेकिन इनोड अभी भी फाइल सिस्टम पर है, बिना छेड़छाड़ किए गए और आप वास्तव में हटाए गए सभी लिंक हैं।
यूनिक्स प्रोग्राम हर समय फाइल सिस्टम के बारे में सोचने के तरीके का उपयोग करते हैं, एक अस्थायी फ़ाइल बनाते हैं, इसे खोलते हैं, नाम हटाते हैं। आपकी फ़ाइल अभी भी मौजूद है लेकिन नाम दूसरों के उपयोग के लिए मुक्त हो गया है और कोई भी इसे देख नहीं सकता है।
"हर समय"? कोई उदाहरण? – Mez
Google को "यूनिक्स सुरक्षित अस्थायी फ़ाइल" के बारे में पूछें और आपको यह दिखाने के लिए तकनीक का पर्याप्त विवरण मिलेगा कि यह जाने-माने और आमतौर पर उपयोग किया जाता है। हालांकि मेरे पास देने के लिए कोई विशिष्ट उदाहरण नहीं हैं, लेकिन मुझे लगता है कि किसी भी सुरक्षा-जागरूक ऐप का उपयोग करता है जो temp फ़ाइलों का उपयोग करता है। –
NT वेरिएंट
openfiles
आदेश है, जो दिखाई देगा जो प्रक्रियाओं जो फ़ाइलों पर हैंडल होता है। हालांकि, सिस्टम ग्लोबल फ्लैग 'ऑब्जेक्ट्स सूची बनाए रखने' की आवश्यकता होती है
ओपनफाइल/स्थानीय /?
आपको बताता है कि यह कैसे करें, और यह भी कि प्रदर्शन प्रदर्शन एक ऐसा करके किया जाता है।
मुझे लगता है कि आप विंडोज के बारे में बहुत पूर्ण हैं। आम तौर पर, यह निष्पादन योग्य के कोड भाग के लिए स्वैप स्थान आवंटित नहीं करता है। इसके बजाए, यह एक्साटेबल & डीएलएल पर लॉक रखता है। यदि छोड़े गए कोड पृष्ठों की फिर से आवश्यकता है, तो वे बस पुनः लोड हो जाते हैं। लेकिन/SWAPRUN के साथ, इन पृष्ठों को स्वैप में रखा जाता है। इसका उपयोग सीडी या नेटवर्क ड्राइव पर एक्जिक्यूटिव के लिए किया जाता है। इसलिए, विंडोज़ को इन फ़ाइलों को लॉक करने की आवश्यकता नहीं है।
नेट के लिए, Shadow Copy को देखो।
लिनक्स फ़ाइलों को लॉक करता है। यदि आप निष्पादित करने वाली फ़ाइल को ओवरराइट करने का प्रयास करते हैं तो आपको "ETXTBUSY" (टेक्स्ट फ़ाइल व्यस्त) मिल जाएगी। हालांकि आप फ़ाइल को हटा सकते हैं, और जब कर्नेल को अंतिम संदर्भ हटा दिया जाता है तो कर्नेल फ़ाइल को हटा देगा। (यदि मशीन को साफ़ रूप से बंद नहीं किया गया था, तो फाइलें सिस्टम की जांच होने पर इन फ़ाइलों को "हटाए गए इनोड में शून्य डी-टाइम" संदेश का कारण होता है, वे पूरी तरह से हटाए नहीं जाते थे, क्योंकि चल रहे प्रक्रिया में उनका संदर्भ था, और अब वे कर रहे हैं।)
यह कुछ प्रमुख फायदे हैं, तो आप निष्पादन को हटाने, जगह है, तो प्रक्रिया पुन: प्रारंभ करके, एक प्रक्रिया चल thats उन्नयन कर सकते हैं। यहां तक कि init को इस तरह अपग्रेड किया जा सकता है, निष्पादन योग्य को प्रतिस्थापित कर सकता है, और इसे एक सिग्नल भेज सकता है, और रीबूट की आवश्यकता के बिना इसे फिर से निष्पादित कर देगा। (यह आमतौर पर आपके पैकेज प्रबंधन प्रणाली द्वारा स्वचालित रूप से स्वचालित रूप से किया जाता है)
विंडोज़ के तहत, उपयोग में आने वाली फ़ाइल को प्रतिस्थापित करना एक बड़ी परेशानी प्रतीत होता है, आमतौर पर यह सुनिश्चित करने के लिए रीबूट की आवश्यकता होती है कि कोई प्रक्रिया चल रही न हो।
कुछ समस्याएं हो सकती हैं, जैसे कि आपके पास बहुत बड़ी लॉगफाइल है, और आप इसे हटा दें, लेकिन उस फ़ाइल को फिर से खोलने के लिए उस फ़ाइल को लॉगिंग करने वाली प्रक्रिया को बताना भूलें, यह संदर्भ रखेगा, और आपको आश्चर्य होगा कि आपकी डिस्क को अचानक और अधिक खाली जगह क्यों नहीं मिली।
तुम भी अस्थायी फ़ाइलों के लिए लिनक्स के तहत इस चाल का उपयोग कर सकते हैं। फ़ाइल खोलें, इसे हटाएं, फिर फ़ाइल का उपयोग जारी रखें। जब आपकी प्रक्रिया निकलती है (चाहे कोई कारण न हो - यहां तक कि बिजली की विफलता भी), फ़ाइल हटा दी जाएगी।
कार्यक्रम lsof और फ्यूज़र (या बस/proc // fd में चारों ओर poking) की तरह आप जान सकते हैं कि प्रक्रियाओं फ़ाइलों को खोलने कि अब एक नाम होता है।
निष्पादन योग्य चलते समय स्मृति के लिए क्रमिक रूप से मैप किए जाते हैं। इसका अर्थ यह है कि निष्पादन योग्य के भाग आवश्यकतानुसार लोड किए जाते हैं। अगर मैप किए जा रहे सभी वर्गों से पहले फाइल को बदल दिया जाता है, तो इससे बड़ी अस्थिरता हो सकती है।
यदि किसी फ़ाइल में निष्पादित कोड लॉक किया जाना चाहिए या नहीं, तो एक डिज़ाइन निर्णय है और एमएस ने बस लॉक करने का निर्णय लिया है, क्योंकि इसमें अभ्यास में स्पष्ट फायदे हैं: इस तरह आपको यह जानने की आवश्यकता नहीं है कि किस संस्करण में संस्करण का उपयोग किया जाता है किस आवेदन से। लिनक्स डिफ़ॉल्ट व्यवहार के साथ यह एक बड़ी समस्या है, जिसे अधिकांश लोगों द्वारा आसानी से अनदेखा किया जाता है। यदि सिस्टम वाइड लिब को प्रतिस्थापित किया गया है, तो आप आसानी से नहीं जान सकते कि कौन से ऐप्स इस तरह के libs के कोड का उपयोग करते हैं, अधिकतर बार आपको सबसे अच्छा मिल सकता है कि पैकेज प्रबंधक उन libs के कुछ उपयोगकर्ताओं को जानता है और उन्हें पुनरारंभ करता है। लेकिन यह केवल सामान्य और अच्छी तरह से चीजों के बारे में जानता है जैसे पोस्टग्रेस और इसकी libs या ऐसे। अधिक दिलचस्प परिदृश्य हैं यदि आप कुछ तृतीय पक्ष libs के खिलाफ अपना स्वयं का एप्लिकेशन विकसित करते हैं और उन्हें प्रतिस्थापित किया जाता है, क्योंकि अधिकांश बार पैकेज प्रबंधक आपके ऐप को नहीं जानता है। और यह न केवल देशी सी कोड की समस्या है या ऐसा है, यह लगभग हर चीज के साथ हो सकता है: बस modd के साथ httpd का उपयोग करें और कुछ पर्ल libs पैकेज प्रबंधक का उपयोग करके स्थापित करें और पैकेज प्रबंधक को किसी भी कारण से उन पर्ले libs को अद्यतन करने दें। यह आपके httpd को पुनरारंभ नहीं करेगा, क्योंकि यह निर्भरता को नहीं जानता है। इस तरह के कई उदाहरण हैं, बस इसलिए कि किसी भी फ़ाइल में किसी भी रनटाइम द्वारा स्मृति में उपयोग में कोड शामिल हो सकता है, जावा, पायथन और ऐसी सभी चीजों के बारे में सोचें।
तो राय रखने का एक अच्छा कारण है कि फ़ाइलों को डिफ़ॉल्ट रूप से लॉक करना एक अच्छा विकल्प हो सकता है। हालांकि, आपको उन कारणों से सहमत होने की आवश्यकता नहीं है।
तो एमएस ने क्या किया? उन्होंने बस एक एपीआई बनाया जो कॉलिंग एप्लिकेशन को यह तय करने का मौका देता है कि फाइलों को लॉक किया जाना चाहिए या नहीं, लेकिन उन्होंने फैसला किया कि इस एपीआई का डिफ़ॉल्ट मान पहले कॉलिंग एप्लिकेशन को एक विशेष लॉक प्रदान करना है। CreateFile और इसके dwShareMode तर्क के आसपास API पर एक नज़र डालें। यही कारण है कि आप कुछ एप्लिकेशन द्वारा उपयोग में फ़ाइलों को हटाने में सक्षम नहीं हो सकते हैं, यह केवल आपके उपयोग के मामले की परवाह नहीं करता है, डिफ़ॉल्ट मानों का उपयोग करता है और इसलिए फ़ाइल के लिए विंडोज द्वारा एक विशेष लॉक प्राप्त होता है।
कृपया उन लोगों पर विश्वास न करें जो आपको विंडोज़ के बारे में कुछ बताते हैं, हैंडल पर रेफ गिनती का उपयोग नहीं करते हैं या हार्डलिंक्स का समर्थन नहीं करते हैं, या यह पूरी तरह गलत है। हैंडल का उपयोग करने वाले लगभग हर एपीआई रेफ गिनती के संबंध में अपना व्यवहार दस्तावेज करता है और आप आसानी से एनटीएफएस के बारे में किसी भी लेख में पढ़ सकते हैं कि यह कार्य में हार्डलिंक्स का समर्थन करता है और हमेशा ऐसा करता है, क्योंकि विंडोज विस्टा के पास सिम्लिंक के लिए भी समर्थन है और हार्डलिंक्स के लिए समर्थन किया गया है read all hard links for a given file और ऐसे में एपीआई प्रदान करके सुधार हुआ।
इसके अतिरिक्त, आप बस फ़ाइल में वर्णन करने के लिए उपयोग की जाने वाली संरचनाओं पर एक नज़र रखना चाहते हैं। NTFS की तुलना में, जो कि बहुत आम है। दोनों एक्सेंट्स की अवधारणा के साथ काम करते हैं, जो डेटा नाम जैसे गुणों से डेटा को अलग करता है, और इनोड्स पुराने के लिए बस एक और नाम है, लेकिन इसकी इसी तरह की अवधारणा है। यहां तक कि विकिपीडिया भी article में दोनों फाइल सिस्टम सूचीबद्ध करता है।
नेट पर अन्य ओएस की तुलना में विंडोज़ में फ़ाइल लॉकिंग के आसपास वास्तव में बहुत सारे एफयूडी हैं, जैसे डीफ्रैग्मेंटेशन की तरह। ;-) इस एफयूडी में से कुछ को Wikipedia पर बस थोड़ा सा पढ़कर बाहर किया जा सकता है।
[व्हाउलॉकएम] (http://www.dr-hoiby.com/WhoLockMe/index.php) नामक एक उपयोगिता है जो एक्सप्लोरर में संदर्भ मेनू में मेनू प्रविष्टि जोड़ती है जो प्रक्रिया (एस) प्रदर्शित कर सकती है किसी दिए गए फ़ाइल को लॉक करना जब आप अजीब फ़ाइल-लॉकिंग त्रुटियां प्राप्त करते हैं तो बेहद उपयोगी। संपादित करें: मुझे पता है कि यह सवाल का जवाब नहीं देता है, लेकिन मैंने सोचा कि यह एक अलग उत्तर वारंट करने के संदर्भ में पर्याप्त उपयोगी था (जैसा कि केवल एक टिप्पणी के लिए विरोध किया गया था)। इस संदर्भ में – JesperE