फ़ाइल लॉकिंग: Difference between revisions

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

 

# कंप्यूटर प्रोसेस ए एक ग्राहक [[डेटाबेस रिकॉर्ड]] को एक फ़ाइल से पढ़ता है जिसमें ग्राहक के खाते की शेष राशि और फोन नंबर सहित खाता जानकारी होती है।

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

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

बाइट-रेंज लॉकिंग प्रकार द्वारा निर्धारित किया जाता है<code>dwFlags</code>में पैरामीटर <code>LockFileEx</code><ref>{{cite web |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfileex#parameters |title=<code>LockFileEx</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2020-07-05}}</ref> फ़ाइल के किसी क्षेत्र को लॉक करने के लिए फ़ंक्शन का उपयोग किया जाता है। [[विंडोज़ एपीआई]] फ़ंक्शन <code>LockFile</code><ref> {{cite web |url=https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfile  |title=<code>LockFile</code> function |series=windows-sdk-content |department=Windows Software Development Toolkit |publisher=Microsoft Corporation |website=Microsoft Docs |access-date=2020-07-05}}</ref> इसका उपयोग भी किया जा सकता है और फ़ाइल के क्षेत्र पर एक विशेष लॉक प्राप्त किया जा सकता है।

कोई भी फ़ाइल जिसमें एक निष्पादन योग्य प्रोग्राम फ़ाइल है जो वर्तमान में कंप्यूटर सिस्टम पर एक प्रोग्राम के रूप में चल रही है (उदाहरण के लिए an <code>[[EXE]]</code>, COM फ़ाइल|<code>COM</code>, डायनामिक-लिंक लाइब्रेरी|<code>DLL</code>, कंट्रोल पैनल एप्लेट्स की सूची (विंडोज़)|<code>CPL</code>या अन्य बाइनरी प्रोग्राम फ़ाइल स्वरूप) आमतौर पर ऑपरेटिंग सिस्टम द्वारा ही लॉक किया जाता है, जिससे किसी भी एप्लिकेशन को इसे संशोधित करने या हटाने से रोका जा सकता है। ऐसा करने के किसी भी प्रयास को साझाकरण उल्लंघन त्रुटि के साथ अस्वीकार कर दिया जाएगा, इस तथ्य के बावजूद कि प्रोग्राम फ़ाइल किसी भी एप्लिकेशन द्वारा नहीं खोली गई है। हालाँकि, कुछ पहुँच की अभी भी अनुमति है। उदाहरण के लिए, एक रनिंग एप्लिकेशन फ़ाइल को निष्पादित करते समय भी उसका नाम बदला या कॉपी (पढ़ा) जा सकता है।

[[फ़ाइल विवरणक]] का उपयोग करके विंडोज़ में एप्लिकेशन द्वारा फ़ाइलों तक पहुंच बनाई जाती है। इन फ़ाइल हैंडल को [[प्रोसेस एक्सप्लोरर]] उपयोगिता के साथ खोजा जा सकता है। इस उपयोगिता का उपयोग हैंडल को पकड़कर रखे गए एप्लिकेशन को समाप्त किए बिना उसे बलपूर्वक बंद करने के लिए भी किया जा सकता है। यह एक अपरिभाषित व्यवहार का कारण बन सकता है, क्योंकि फोर्स-क्लोज्ड हैंडल का उपयोग करते समय प्रोग्राम को एक अप्रत्याशित त्रुटि प्राप्त होगी और यहां तक ​​कि एक अप्रत्याशित फ़ाइल पर भी काम हो सकता है क्योंकि हैंडल नंबर को पुनर्चक्रित किया जा सकता है।{{citation needed|date=November 2017}}

यूनिक्स-जैसे ऑपरेटिंग सिस्टम ([[लिनक्स]] और ऐप्पल के मैकओएस सहित) आमतौर पर खुली हुई फ़ाइलों को स्वचालित रूप से लॉक नहीं करते हैं। यूनिक्स के विभिन्न प्रकारों में कई प्रकार की फ़ाइल-लॉकिंग प्रणालियाँ उपलब्ध हैं, और कई ऑपरेटिंग सिस्टम अनुकूलता के लिए एक से अधिक प्रकार का समर्थन करते हैं। सबसे आम तंत्र है <code>{{man|sh|fcntl|SUS||inline}}</code>. ऐसे दो अन्य तंत्र हैं {{man|2|flock|FreeBSD||inline}} और <code>{{man|3|lockf|FreeBSD||inline}}</code>, जिनमें से प्रत्येक को शीर्ष पर लागू किया जा सकता है <code>fcntl</code> या अलग से लागू किया जा सकता है <code>fcntl</code>. हालाँकि कुछ प्रकार के लॉक को अनिवार्य रूप से कॉन्फ़िगर किया जा सकता है, यूनिक्स के तहत फ़ाइल लॉक डिफ़ॉल्ट रूप से सलाह है। इसका मतलब यह है कि सहयोगी प्रक्रियाएं आपस में किसी फ़ाइल तक पहुंच को समन्वित करने के लिए लॉक का उपयोग कर सकती हैं, लेकिन असहयोगी प्रक्रियाएं भी लॉक को अनदेखा करने और फ़ाइल को किसी भी तरीके से एक्सेस करने के लिए स्वतंत्र हैं। दूसरे शब्दों में, फ़ाइल लॉक केवल अन्य फ़ाइल लॉकर को लॉक करता है, I/O को नहीं।

दो प्रकार के ताले पेश किए जाते हैं: साझा ताले और विशेष ताले। के मामले में <code>fcntl</code>, विभिन्न प्रकार के ताले किसी फ़ाइल के विभिन्न अनुभागों (बाइट रेंज) पर या फिर पूरी फ़ाइल पर लागू किए जा सकते हैं। साझा ताले को एक ही समय में कई प्रक्रियाओं द्वारा रखा जा सकता है, लेकिन एक विशेष लॉक को केवल एक प्रक्रिया द्वारा रखा जा सकता है, और साझा ताले के साथ सह-अस्तित्व नहीं रखा जा सकता है। साझा लॉक प्राप्त करने के लिए, एक प्रक्रिया को तब तक इंतजार करना होगा जब तक कि कोई भी प्रक्रिया कोई विशेष लॉक न रखे। एक विशेष लॉक प्राप्त करने के लिए, एक प्रक्रिया को तब तक इंतजार करना होगा जब तक कि किसी भी प्रक्रिया में किसी भी प्रकार का लॉक न हो। द्वारा बनाए गए तालों के विपरीत <code>fcntl</code>, जिनके द्वारा बनाया गया है <code>flock</code> भर में संरक्षित हैं <code>fork</code>एस, उन्हें फोर्किंग सर्वर में उपयोगी बनाता है। इसलिए एक से अधिक प्रक्रियाओं के लिए एक ही फ़ाइल पर एक विशेष लॉक रखना संभव है, बशर्ते ये प्रक्रियाएँ एक पारिवारिक संबंध साझा करती हों और एक ही प्रक्रिया में अनन्य लॉक शुरू में डुप्लिकेट होने से पहले बनाया गया हो। <code>fork</code>.

फ़ाइल लॉक फ़ाइल नाम के बजाय वास्तविक फ़ाइल पर लागू होते हैं। यह महत्वपूर्ण है क्योंकि यूनिक्स एक ही फ़ाइल को संदर्भित करने के लिए एकाधिक नामों की अनुमति देता है। गैर-अनिवार्य लॉकिंग के साथ, यह कई प्रक्रियाओं से फ़ाइलों तक पहुंचने में काफी लचीलापन प्रदान करता है। दूसरी ओर, सहकारी लॉकिंग दृष्टिकोण तब समस्याएँ पैदा कर सकता है जब कोई प्रक्रिया अन्य प्रक्रियाओं द्वारा निर्धारित फ़ाइल लॉक का पालन किए बिना किसी फ़ाइल को लिखती है।

| access-date = 2011-10-08}}</ref> ऐसे सिस्टम पर, एक फ़ाइल जिसका <code>setgid</code> बिट चालू है लेकिन जिसका समूह निष्पादन बिट उस फ़ाइल को खोलने पर बंद है, यदि अंतर्निहित फ़ाइल सिस्टम इसका समर्थन करता है तो स्वचालित अनिवार्य लॉकिंग के अधीन होगा। हालाँकि, गैर-स्थानीय एनएफएस विभाजन इस बिट की उपेक्षा करते हैं।<ref>{{cite web

| access-date = 2011-10-08}}</ref> यदि कोई फ़ाइल अनिवार्य लॉकिंग के अधीन है, तो उस क्षेत्र से पढ़ने का प्रयास जो एक विशेष लॉक के साथ लॉक है, या किसी ऐसे क्षेत्र में लिखने का प्रयास करता है जो एक साझा या एक्सक्लूसिव लॉक के साथ लॉक है, लॉक जारी होने तक ब्लॉक रहेगा। यह रणनीति सबसे पहले सिस्टम V में उत्पन्न हुई, और आज इसे [[सोलारिस (ऑपरेटिंग सिस्टम)]], [[एचपी-यूएक्स]] और लिनक्स ऑपरेटिंग सिस्टम में देखा जा सकता है। हालाँकि, यह POSIX का हिस्सा नहीं है, और BSD-व्युत्पन्न ऑपरेटिंग सिस्टम जैसे [[FreeBSD]], [[OpenBSD]], [[NetBSD]] और Apple का macOS इसका समर्थन नहीं करते हैं।<ref>{{cite book |author1=Viega, John |edition=1st |author2=Messier, Matt |year=2003 |title=C और C++ के लिए सुरक्षित प्रोग्रामिंग कुकबुक|publisher=O'Reilly Media |location=Sabastopol, CA |isbn=978-0-596-00394-4 |chapter=2.8 Locking Files |page=792 |url=http://shop.oreilly.com/product/9780596003944.do |quote=Support for mandatory locks varies greatly from one Unix variant to another. Both Linux and Solaris support mandatory locks, but [[Darwin (operating system)|Darwin]], [[FreeBSD]], [[NetBSD]], and [[OpenBSD]] do not, even though they export the interface used by Linux and Solaris to support them. On such systems, this interface creates advisory locks. Support for mandatory locking does not extend to NFS.}}</ref> लिनक्स विशेष के माध्यम से अनिवार्य लॉकिंग का भी समर्थन करता है<code>-o mand</code>फ़ाइल सिस्टम माउंटिंग के लिए पैरामीटर (<code>{{man|8|mount|Linux||inline}}</code>), लेकिन इसका उपयोग शायद ही कभी किया जाता है।

=== {{Anchor|POSIX}}समस्याएँ ===

चाहे और कैसे <code>flock</code> [[ नेटवर्क फ़ाइल सिस्टम (प्रोटोकॉल) ]] जैसे नेटवर्क फाइल सिस्टम पर लॉक का काम कार्यान्वयन पर निर्भर है। [[बीएसडी]] सिस्टम पर, <code>flock</code> एनएफएस-माउंटेड विभाजन पर फ़ाइल के लिए खुले फ़ाइल डिस्क्रिप्टर पर कॉल सफल [[एनओपी (कोड)]]|नो-ऑप्स हैं। 2.6.12 से पहले Linux पर, <code>flock</code> एनएफएस फाइलों पर कॉल केवल स्थानीय रूप से कार्य करेगी। कर्नेल 2.6.12 और उससे ऊपर का कार्यान्वयन <code>flock</code> POSIX बाइट-रेंज लॉक का उपयोग करके NFS फ़ाइलों पर कॉल करता है। ये लॉक लागू करने वाले अन्य एनएफएस क्लाइंट को दिखाई देंगे <code>fcntl</code>-स्टाइल POSIX लॉक, लेकिन जो नहीं करते उनके लिए अदृश्य।<ref>{{cite web |url=http://nfs.sourceforge.net/ |series=Linux NFS FAQ: D |title=सामान्यतः उत्पन्न होने वाले त्रुटि संदेश|website=nfs.sourceforge.net |publisher=Source Forge}}</ref>

लॉक विफलता का एक स्रोत तब होता है जब बफ़र किए गए I/O में ऑपरेटिंग सिस्टम बफ़र पूल के बजाय उपयोगकर्ता के स्थानीय कार्यक्षेत्र में बफ़र्स निर्दिष्ट होते हैं। <code>fread</code> और <code>fwrite</code> आमतौर पर बफर्ड I/O करने के लिए उपयोग किया जाता है, और एक बार फ़ाइल का एक अनुभाग पढ़ने के बाद, उसी अनुभाग को पढ़ने का एक और प्रयास, सबसे अधिक संभावना है, स्थानीय बफर से डेटा प्राप्त करेगा। समस्या यह है कि उसी फ़ाइल से जुड़े किसी अन्य उपयोगकर्ता के पास अपने स्वयं के स्थानीय बफ़र्स हैं, और उनके लिए भी यही हो रहा है। एक <code>fwrite</code> द्वारा बफ़र से प्राप्त डेटा का <code>fread</code> क्या ''नहीं'' फ़ाइल से ही डेटा प्राप्त कर रहा होगा, और कोई अन्य उपयोगकर्ता इसे बदल सकता था। दोनों उपयोग कर सकते थे <code>flock</code> विशिष्ट पहुंच सुनिश्चित करने के लिए, जो एक साथ लिखने से रोकता है, लेकिन चूंकि रीड्स बफर से पढ़ रहे हैं, न कि फ़ाइल से, उपयोगकर्ता #1 द्वारा बदला गया कोई भी डेटा उपयोगकर्ता #2 (ओवर-राइट) द्वारा खो सकता है। इस समस्या का सबसे अच्छा समाधान अनबफ़र्ड I/O का उपयोग करना है (<code>read</code> और <code>write</code>) साथ <code>flock</code>, जिसका अर्थ उपयोग करना भी है <code>lseek</code> के बजाय <code>fseek</code> और <code>ftell</code>. बेशक, आपको फ़ंक्शन पैरामीटर और लौटाए गए परिणामों के लिए समायोजन करना होगा। सामान्यतया, साझा फ़ाइलों के साथ उपयोग किए जाने पर बफ़र्ड I/O असुरक्षित होता है।

AmigaOS में, किसी फ़ाइल (या निर्देशिका) पर लॉक का उपयोग करके प्राप्त किया जा सकता है <code>Lock</code> फ़ंक्शन (में <code>dos.library</code>). एक लॉक साझा किया जा सकता है (अन्य प्रक्रियाएं फ़ाइल/निर्देशिका को पढ़ सकती हैं, लेकिन इसे संशोधित या हटा नहीं सकती हैं), या विशेष ताकि केवल वह प्रक्रिया जो सफलतापूर्वक लॉक प्राप्त कर ले, ऑब्जेक्ट तक पहुंच या संशोधित कर सके। ताला पूरी वस्तु पर है, उसके किसी भाग पर नहीं। लॉक को इसके साथ जारी किया जाना चाहिए <code>UnLock</code> फ़ंक्शन: यूनिक्स के विपरीत, प्रक्रिया समाप्त होने पर ऑपरेटिंग सिस्टम ऑब्जेक्ट को अंतर्निहित रूप से अनलॉक नहीं करता है।

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

* सिस्टम कॉल जो एक फ़ाइल बनाती है, लेकिन यदि फ़ाइल पहले से मौजूद है तो विफल हो जाती है। (सिस्टम कॉल C या C++ जैसी भाषाओं से उपलब्ध हैं, और शेल स्क्रिप्ट [[noclobber]] का उपयोग कर सकती हैं)