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

विंडोज ReadDirectoryChangesW

विंडोज ऑपरेटिंग सिस्टम के लिए, एक अद्भुत ReadDirectoryChangesW फ़ंक्शन है जो एक निर्देशिका के लिए परिवर्तनों का एक सेट देता है, जिसमें पुनरावर्ती (bWatchSubtree) के लिए एक ध्वज शामिल है। इस प्रकार, निर्देशिका में परिवर्तनों को ट्रैक करने का कार्यान्वयन मुश्किल नहीं है और उसी dklab_realsync कार्यान्वयन में कोड की 80 पंक्तियाँ या 3.5 Kb लगती हैं। दिलचस्प है, विंडोज में, इन घटनाओं को एसएमबी के माध्यम से भी समर्थन किया जाता है!

हालाँकि, कुछ ख़ास नुकसान हैं:

• परिवर्तन बफ़र का अंतिम आकार, जिसके बाद ईवेंट कतार ओवरफ़्लो हो जाएगी और ये ईवेंट खो जाएंगे
• वॉचडॉग पैकेज के लिए प्रलेखन के अनुसार, एफएस में परिवर्तन दिखाई देने से पहले एक चालन घटना भेजी जाती है
• एक नेटवर्क FS के लिए बफर का आकार 64 Kb तक सीमित है

निष्कर्ष: ReadDirectoryChangesW फ़ंक्शन आपको फ़ाइलों में सभी घटनाओं के बारे में आसानी से पता लगाने की अनुमति देता है, लेकिन घटना कतार पूर्ण हो सकती है और फिर आपको पूर्ण एफएस स्कैन करने की आवश्यकता होगी। प्रासंगिक बनने से पहले घटनाओं को वितरित करना भी संभव है।

मैक ओएस एक्स, FSEvents

मैक ओएस एक्स में फ़ाइल सिस्टम परिवर्तनों को ट्रैक करने के लिए एक सुविधाजनक और सरल एपीआई भी है जिसे FSEvents कहा जाता है। इस एपीआई का उपयोग करना, डेमन का सबसे सरल कार्यान्वयन कोड की 50 लाइनें या 1.8 केबी है। कतार अतिप्रवाह नहीं कर सकती है!), लेकिन यदि fseventsd डेमॉन "क्रैश" के लिए एक पूर्ण स्कैन की आवश्यकता हो सकती है। यह ध्यान देने योग्य है कि संस्करण 10.7 तक यह एपीआई फ़ाइल द्वारा परिवर्तन प्रदान नहीं करता है, यह केवल निर्देशिकाओं की रिपोर्ट करता है जिसमें कुछ बदल गया है। चूंकि घटनाएं कहीं भी गायब नहीं होती हैं और लॉग की जाती हैं ( FSEvents सेवा घटनाओं को लगातार, प्रति-वॉल्यूम डेटाबेस में संग्रहीत करती है ), निर्देशिका के लिए परिशुद्धता के साथ बारीकियों से डिस्क स्थान बचाता है।

निष्कर्ष: मैक ओएस एक्स के लिए FSEvents एपीआई ऐसे सभी API में सबसे असामान्य है। कतार में भीड़ नहीं है और अतीत से घटनाओं को प्राप्त करने का अवसर भी है। हालाँकि, ईवेंट विवरणिंग निर्देशिका (संस्करण 10.7 तक) के लिए सटीक है, जिसका अर्थ है कि डेमॉन फ़ाइलों को सिंक्रनाइज़ करने में कम कुशल है।

लिनक्स, inotify

लिनक्स वेनिला कर्नेल में, निर्देशिका परिवर्तन को ट्रैक करने का एक तरीका है - इनोटिफाई । इस एपीआई के लिए अच्छा और विस्तृत दस्तावेज है, लेकिन पुनरावर्ती परिवर्तन ट्रैकिंग के लिए कोई समर्थन नहीं है! इसके अलावा, inotify की अधिकतम संख्या में वस्तुओं की एक सीमा होती है, जिनकी निगरानी की जा सकती है। डेमन का सबसे सरल कार्यान्वयन पहले से ही कोड या 8 केबी की 250 लाइनें लेता है। Dietlibc का उपयोग करके स्टेटिक असेंबली में लगभग 14 kb लगते हैं। एक और अप्रिय क्षण यह है कि एप्लिकेशन को वॉच डिस्क्रिप्टर (हमारे मामले में, यह हमेशा एक निर्देशिका है) और नाम के बीच पत्राचार बनाए रखना चाहिए। एक फ़ंक्शन inotify_add_watch है , जिसे मॉनिटर की गई निर्देशिका के लिए पथ पास किया गया है, लेकिन कोई वापसी नहीं है - inotify_get_path, जो पास किए गए डिस्क्रिप्टर द्वारा इसी पथ को लौटाएगा। ईवेंट्स में केवल डिस्क्रिप्टर और रिलेटिव पाथ को डायरेक्टरी के अंदर बदले हुए फाइल में रखा गया है।

Inotify के माध्यम से पुनरावर्ती निर्देशिका ट्रैकिंग के नुकसान:

• कतार अतिप्रवाह की संभावना (कतार लंबाई / proc / sys / fs / inotify / max_queued_events में सेट है)
• अधिकतम ट्रैकिंग ऑब्जेक्ट्स (सीमा / सेट / sys / fs / inotify / max_userwatch.com) पर सीमित करें
• पुनरावर्ती निर्देशिका ट्रैकिंग का अभाव
• निर्देशिका बनाए जाने पर मामले को अलग से संभालने की आवश्यकता है (उदाहरण के लिए mkdir -pa / b / c)। आपको एक घटना प्राप्त होगी कि निर्देशिका "ए" बनाई गई है, लेकिन जब आप इस निर्देशिका पर हैंडलर लटकाते हैं, तो वे पहले से ही इसमें एक और निर्देशिका बना सकते हैं और इस बारे में घटना आपके पास नहीं आएगी।
• पूर्णांक ओवरफ़्लो वॉच डिस्क्रिप्टर (wd) की सैद्धांतिक संभावना, क्योंकि यह uint32 द्वारा निर्दिष्ट है

फ्रीबीएसडी, मैक ओएस एक्स, केक्यूयू

FreeBSD और Mac OS X आपको kqueue का उपयोग करके परिवर्तनों को ट्रैक करने की अनुमति देते हैं, जो इसकी विशेषताओं में इनोटिफाई के समान है और इसमें निर्देशिकाओं को पुनरावृत्ति करने की क्षमता भी नहीं है। इसके अलावा, kqueue तर्कों के रूप में खुले फ़ाइल डिस्क्रिप्टर (निर्देशिका) को स्वीकार करता है, इसलिए इस एपीआई का उपयोग करते समय मॉनिटर किए गए निर्देशिकाओं की संख्या पर प्रतिबंध और भी कड़े हैं।

कुल:

तंत्र	कतार अतिप्रवाह	पुनरावर्ती?	मैक्स। वस्तुओं	विनिर्देश
ReadDirectoryChangesW	हां	हां	-	फ़ाइल
FSEvents	नहीं	हां	-	फ़ाइल (10.7+)
inotify	हां	नहीं	8192	फ़ाइल
kqueue	हां	नहीं	1024	फ़ाइल

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

* Www.alexblogger.com/2008_01_01_archive.html से लिया गया चित्र