fsnotify Go द्वारा फाइल और डायरेक्टरी मॉनिटरिंग का कार्यान्वयन

fsnotify गो में लिखी गई एक फ़ाइल सिस्टम सूचना पुस्तकालय है, जो फ़ाइल सिस्टम में फ़ाइलों और निर्देशिकाओं में होने वाले परिवर्तनों का निगरानी कर सकता है और जब परिवर्तन होते हैं, तो अनुप्रयोग को सूचित कर सकता है। यह क्रॉस-प्लेटफ़ॉर्म कार्य का समर्थन करता है और लिनक्स, macOS, और विंडोज़ जैसे विभिन्न ऑपरेटिंग सिस्टम पर चल सकता है। fsnotify विभिन्न ऑपरेटिंग सिस्टम की फ़ाइल सिस्टम सूचना यांत्रिकियों का उपयोग करता है, जैसे लिनक्स पर inotify, macOS पर FSEvents, और विंडोज़ पर ReadDirectoryChangesW।

Go 1.17 या उसके बाद के संस्करण का उपयोग करना आवश्यक है; पूरा दस्तावेज़ीकरण यहां देखा जा सकता है: https://pkg.go.dev/github.com/fsnotify/fsnotify।

विभिन्न ऑपरेटिंग सिस्टमों का समर्थन:

Backend	Operating System	Status
inotify	Linux	Supported
kqueue	BSD, macOS	Supported
ReadDirectoryChangesW	Windows	Supported
FEN	illumos	Supported
fanotify	Linux 5.9+	अभी तक समर्थित नहीं
AHAFS	AIX	AIX शाखा; प्रायोगिक सुविधा, प्रबंधकों और परीक्षण वातानुकूलता की कमी के कारण
FSEvents	macOS	x/sys/unix समर्थन की आवश्यकता है
USN Journals	Windows	x/sys/windows समर्थन की आवश्यकता है
Polling	सभी	अभी तक समर्थित नहीं

एंड्रॉइड और सोलेरिस, जिसमें लिनक्स और इल्लुमोस शामिल होना चाहिए, अभी तक परीक्षण नहीं किए गए हैं।

उपयोग मामला

fsnotify के उपयोग के मामले निम्नलिखित स्थितियों के लिए हो सकते हैं, इनमें से सीमित नहीं हैं:

वास्तविक समय में फ़ाइल समक्रियकरण: fsnotify वास्तविक समय में फ़ाइल सिस्टम में परिवर्तनों का निगराना कर सकता है, जिससे वास्तविक समय में फ़ाइल समक्रियकरण को क्रियान्वयन के लिए उपयुक्त बनाया जा सकता है। स्रोत फ़ाइल में परिवर्तन होने पर, परिवर्तन स्वीकरणता को तुरंत लक्षित फ़ाइल में समक्रियकरण करने के लिए सुनिश्चित कर सकते हैं।
स्वत:त्र निर्माण: fsnotify परियोजना के स्रोत कोड और निर्भरता फ़ाइलों में परिवर्तन का निगराना कर सकता है, जब परिवर्तन होता है, तो निर्माण कमांड को आरंभ करता है, जिससे स्वत:त्र निर्माण संभव होता है। इससे मैनुअल निर्माण की गयी लागत और प्रगति को सहायक बनाया जा सकता है।
फाइल बैकअप: fsnotify फ़ाइलों या निर्देशिकाओं में परिवर्तन का निगराना कर सकता है और परिवर्तन होने पर तत्काल बैकअप को प्रारंभ कर सकता है। यह सुनिश्चित करता है कि डेटा की सुरक्षा बनी रहती है और फ़ाइल की हानि या क्षति के कारण डेटा का नुकसान न हो।
वास्तविक समय में लॉग निगरानी: fsnotify सृजन, संशोधन, और हटाने जैसी कार्रवाईयों का निगरानी कर सकता है, जिससे लोग फ़ाइलों में परिवर्तन होने पर लॉग निगरानी कार्यक्रमों को सक्रिय करता है, जिससे लोग संविदान में परिवर्तनों का वास्तविक समय में निगराना कर सकते हैं।
फ़ाइल सिस्टम सुरक्षा निगरानी: fsnotify फ़ाइल सिस्टम में सुरक्षा घटनाओं का निगराना कर सकता है, जैसे फ़ाइल पहुंच, संशोधन, और हटाना। इससे फ़ाइल सिस्टम की सुरक्षा निगरानी संभव होती है, गैर-सुरक्षित घटनाओं की पहचान और रिकॉर्डिंग को तुरंत प्राप्त किया जा सकता है।

उपयोग मामले

एक मूल उदाहरण:

package main

import (
    "log"

    "github.com/fsnotify/fsnotify"
)

func main() {
    // एक नया दर्शक बनाएँ।
    watcher, err := fsnotify.NewWatcher()
    if err != nil {
        log.Fatal(err)
    }
    defer watcher.Close()

    // घटनाओं के लिए सुनना शुरू करें।
    go func() {
        for {
            select {
            case event, ok := <-watcher.Events:
                if !ok {
                    return
                }
                log.Println("Event:", event)
                if event.Has(fsnotify.Write) {
                    log.Println("Modified file:", event.Name)
                }
            case err, ok := <-watcher.Errors:
                if !ok {
                    return
                }
                log.Println("Error:", err)
            }
        }
    }()

    // निगरानी की आवश्यकता वाला मार्ग जोड़ें।
    err = watcher.Add("/tmp")
    if err != nil {
        log.Fatal(err)
    }

    // मुख्य गोरूटीन को ब्लॉक करें।
    <-make(chan struct{})
}

और अधिक उदाहरण यहां देखे जा सकते हैं cmd/fsnotify और निम्नलिखित कमांड का उपयोग करके चलाये जा सकते हैं:

% go run ./cmd/fsnotify

और अधिक विस्तृत दस्तावेज़ीकरण से यहां प्राप्त किया जा सकता है: https://pkg.go.dev/github.com/fsnotify/fsnotify

अक्सर पूछे जाने वाले प्रश्न

क्या फ़ाइल को किसी अन्य निर्देशिका में ले जाया जाएगा तो भी उसे निगरानी किया जाएगा?

नहीं, केवल अगर आप उस स्थान को निगरानी कर रहे हैं जहाँ यह ले जाया जाता है।

क्या यह सबडायरेक्टरी मॉनिटर करता है?

नहीं, आपको हर डायरेक्टरी के लिए मॉनिटरिंग जोड़नी होगी जिसे आप मॉनिटर करना चाहते हैं (रिकर्सिव मॉनिटरिंग की योजना है: #18).

क्या मुझे गोरोूटीन में त्रुटि और घटना चैनल दोनों को समय-समय पर समीक्षा करनी चाहिए?

हाँ, आप select का उपयोग करके एक ही गोरोूटीन से दोनों चैनल से पढ़ सकते हैं (आपको प्रत्येक चैनल के लिए अलग-अलग गोरोूटीन शुरू करने की आवश्यकता नहीं है; उदाहरण देखें).

NFS, SMB, FUSE, /proc, या /sys पर सूचनाएँ क्यों काम नहीं करती हैं?

fsnotify को कार्यात्मक रूप से काम करने के लिए आधारित ऑपरेटिंग सिस्टम से समर्थन की आवश्यकता होती है। वर्तमान NFS और SMB प्रोटोकॉल फ़ाइल सूचनाओं के नेटवर्क स्तर का समर्थन नहीं प्रदान करते हैं, और /proc और /sys वर्चुअल फ़ाइल सिस्टम भी समर्थन नहीं प्रदान करते।

इसे एक पोलिंग वॉचर का उपयोग करके ठीक किया जा सकता है (#9), लेकिन यह अभी तक लागू नहीं किया गया है।

मैं क्यों बहुत सारी Chmod घटनाएँ प्राप्त कर रहा हूँ?

कुछ कार्यक्रमों में बहुत सारे विशेषता परिवर्तन उत्पन्न कर सकते हैं, जैसे मैकओएस पर स्पॉटलाइट, एंटीवायरस कार्यक्रम, बैकअप एप्लीकेशन्स, और कुछ और जाने माने अनुप्रयोग। सामान्यत: इन Chmod घटनाओं को अनदेखा कर देना सबसे अच्छा प्रयास होता है क्योंकि वे अक्सर अनुपयोगी होते हैं और समस्याएँ उत्पन्न कर सकते हैं।

मैकओएस पर स्पॉटलाइट का इंडेक्सिंग एकाधिक घटनाओं का कारण बन सकता है (संदर्भ देखें: #15). एक अस्थायी समाधान है कि अपने फोल्डर को स्पॉटलाइट गोपनीयता सेटिंग्स में जोड़ें, जब तक हमें नेटिव FSEvents अनुमानणा नहीं मिल जाता है (संदर्भ देखें: #11)।

फ़ाइलें देखना अच्छी तरह से काम नहीं करता

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

इस परिणामस्वरूप, विद्युत अवरोधन या दुर्घटना एक आधा लिखी फाइल का परिणाम नहीं देंगे।

जनरल में, मूलत: एक अस्थायी समाधान है जो यह कर सकता है। मूलत: वीजरी और संक्षेपक अनुप्रयोगों को छोड़ना सबसे अच्छा अभ्यास होता है

मूल डायरेक्टरी को देखें और Event.Name का उपयोग करें ताकि आप उन फाइलों को निकाल सकें जिन्हें आप देखना नहीं चाहते हैं। cmd/fsnotify/file.go में एक उदाहरण है।

विशेष प्लेटफार्म के लिए नोट्स

Linux

जब एक फाइल हटाई जाती है, तो REMOVE घटना जब तक सभी फाइल डिस्क्रिप्टर बंद नहीं होते तक जारी नहीं होगी; इस समय, एक CHMOD घटना जारी की जाएगी:

fp := os.Open("file")
os.Remove("file")        // CHMOD
fp.Close()               // REMOVE

यह इनोटिफाई द्वारा भेजी गई इवेंट है, इसलिए उसमें बहुत से परिवर्तन नहीं करने चाहिए।

fs.inotify.max_user_watches सिस्कटल वेरिएबल यूजर के प्रति अधिकतम वाचनों की अधिकतम संख्या निर्धारित करता है, और fs.inotify.max_user_instances यूजर के प्रति इनोटिफाई इंस्टेंस की अधिकतम संख्या निर्धारित करता है। आपकी द्वारा बनाई गई प्रत्येक वॉचर एक "इंस्टेंस" है, और आपके द्वारा जोड़े गए प्रत्येक पथ एक "वाच" है।

इन्हें /proc में भी पाया जा सकता है, /proc/sys/fs/inotify/max_user_watches और /proc/sys/fs/inotify/max_user_instances के पाथ्स के साथ।

इन्हें बढ़ाने के लिए, आप sysctl का उपयोग कर सकते हैं या मूल फाइल में मान लिख सकते हैं:

sysctl fs.inotify.max_user_watches=124983
sysctl fs.inotify.max_user_instances=128

इन बदलावों को प्रभावी बनाने के लिए, आप /etc/sysctl.conf या /usr/lib/sysctl.d/50-default.conf संपादन कर सकते हैं (यह विवरण प्रत्येक Linux वितरण के लिए अलग हो सकते हैं, कृपया अपने वितरण के दस्तावेज़ का संदर्भ दें):

fs.inotify.max_user_watches=124983
fs.inotify.max_user_instances=128

सीमा तक पहुंचना "डिवाइस पर कोई जगह उपलब्ध नहीं" या "बहुत सारी खुली फाइलें" त्रुटियों का परिणाम देगा।

kqueue (macOS, सभी BSD सिस्टम)

kqueue में प्रत्येक अदरबार फ़ाइल के लिए एक फाइल डिस्क्रिप्टर खोलने की आवश्यकता होती है; इसलिए, यदि आप पांच फ़ाइलों को समाविष्ट निरीक्षित कर रहे हैं, तो यहा Contributor: @PriyanshiGupta06 instead of छह फाइल डिस्क्रिप्टर हैं। इन प्लेटफार्मों पर, आप जल्दी से सिस्टम की "अधिकतम खुली फाइलें" सीमा तक पहुंच जाएगें।

आप सिस्टम की "अधिकतम खुली फाइलें" सीमा को नियंत्रित करने के लिए sysctl चर चर (कर्न.maxfilesperproc') मैनू कर सकते हैं।