fsnotify Go کا عمل درآمد برائے فائل اور ڈائریکٹری مانیٹرنگ

fsnotify ایک فائل نظام کی اطلاعاتی کتابخانہ ہے جو گو میں لکھی گئی ہے، جو فائل نظام میں فائلوں اور ڈائرکٹریوں کی تبدیلیوں کو نگرانی کر سکتی ہے اور درخواست دینے والے کو تبدیلیوں کی اطلاع دے سکتی ہے۔ یہ مختلف عملی نظاموں پر عمل کرتا ہے اور لینکس، macOS، اور ونڈوز جیسے مختلف عملی نظاموں پر چلایا جا سکتا ہے۔ fsnotify مختلف عملی نظاموں کی فائل نظام کی اطلاعیں کا استعمال کرتا ہے، جیسے کہ لینکس پر inotify، macOS پر FSEvents، اور ونڈوز پر ReadDirectoryChangesW۔

Go 1.17 یا اس کے بعد کے ورژن کا استعمال کرنا ضروری ہے، مکمل دستاویزات یہاں دستیاب ہیں: https://pkg.go.dev/github.com/fsnotify/fsnotify

مختلف عملی نظاموں کی حمایت:

اندروئیڈ اور سولیرس، جو لینکس اور illumos شامل کرنا چاہئے، اب تک ٹیسٹ نہیں کیے گئے ہیں۔

استعمال کے مواقع

fsnotify کے استعمال کے مواقع مندرجہ ذیل ہیں لیکن ان سے محدود نہیں ہیں:

1. واقعی وقت فائل ہم آہنگی: fsnotify فائل نظام میں تبدیلیوں کو واقعی وقت میں نگرانی کر سکتا ہے، جس سے واقعی وقت میں فائل ہم آہنگی کو نافذ کرنے کے لیے موزوں ہوتا ہے۔ جب مقصد کی فائل میں تبدیلیاں آتی ہیں، تبدیلیاں فوراً ہدف فائل میں ہم آہنگ کر سکتی ہیں، یہ یقینی بنایں کہ فائلوں کی ہم آہنگی محفوظ ہے۔
2. خود کار تعمیر: fsnotify مشروع کی ماخذ کوڈ اور تابع کی فائلوں میں تبدیلیوں کو نظروں میں رکھ سکتا ہے، جب تبدیلیاں آتی ہیں تو تعمیر کے حکم دینے والے کمانڈوں کا آغاز کرتا ہے، جس سے خود کار تعمیر حاصل ہوتی ہے۔ یہ دستی تعمیر کے وقت اور محنت کے وقت کو بچا سکتا ہے اور ترقی کی کارکردگی کو بہتر بنا سکتا ہے۔
3. فائل بیک اپ: fsnotify فائلوں یا ڈائرکٹریوں کی تبدیلیوں کو نگرانی کر سکتا ہے جو بیک اپ کرنے کی ضرورت ہوتی ہے اور جب تبدیلیاں آتی ہیں تو فوراً بیک اپ کرتا ہے۔ یہ یقینی بناتا ہے کہ ڈیٹا کی حفاظت ہوتی ہے اور فائل کی کمی یا نقصان کی وجہ سے ڈیٹا کا نقصان نہیں ہوتا۔
4. واقعی وقت لاگ نگرانی: fsnotify لاگ فائلوں کی تخلیق، ترتیب دینے، اور حذف کرنے جیسی کاموں کی نگرانی کر سکتا ہے، جب لاگ فائلوں میں تبدیلیاں آتی ہیں تو واقعی وقت میں تبدیلیوں کی لاگ مانیٹرنگ پروگرامز کو موسیقی کرتا ہے اور لاگ مواد میں تبدیلیوں کی نگرانی کرتا ہے۔
5. فائل نظام کی حفاظتی نگرانی: fsnotify فائل نظام میں حفاظتی واقعات، مثلاً فائل رسائی، ترتیب دینا، اور حذف کا نگرانی کر سکتا ہے۔ یہ فائل نظام کی حفاظتی نگرانی کی اجازت دیتا ہے، جلدی سے غیرمحفوظ واقعات کی شناخت کرنے اور ریکارڈ کرنے کی اجازت دیتا ہے۔

استعمال کا مثال

ایک بنیادی مثال:

package main

import (
    "log"

    "github.com/fsnotify/fsnotify"
)

func main() {
    // نیا دیکھوا بنائیں۔
    watcher، err := fsnotify.NewWatcher()
    اگر err != nil {
        log.Fatal(err)
    }
    استراحت watcher.Close()

    // واقعات کے لیے منصوبہ شروع کریں۔
    go func() {
        for {
            منتخب کریں {
            case event، ok := <-watcher.Events:
                اگر !ok {
                    لوٹو
                }
                log.Println("واقعہ:", event)
                اگر event.Has(fsnotify.Write) {
                    log.Println("موذود فائل:", event.Name)
                }
            case err، ok := <-watcher.Errors:
                اگر !ok {
                    لوٹو
                }
                log.Println("غلطی:", err)
            }
        }
    }()

    // نگرانی کرنے والے راستے شامل کریں۔
    err = watcher.Add("/tmp")
    اگر err != nil {
        log.Fatal(err)
    }

    // مین گوروٹین بلاک کریں۔
    <-make(chan struct{})
}

ورونے کی کام کا مثال cmd/fsnotify میں اور مندرجہ ذیل کمانڈ کا استعمال کرتے ہوئے دیکھی جا سکتی ہیں:

% go run ./cmd/fsnotify

مزید تفصیلی دستاویزات godoc میں دستیاب ہیں: https://pkg.go.dev/github.com/fsnotify/fsnotify

عام سوالات

کیا یہ منظر برقرار رہے گا، اگر فائل کسی اور ڈائریکٹری میں منتقل کر دی جائے؟

نہیں، اگر آپ منزل جہاں یہ منتقل ہوئی ہے اس کی نگرانی کر رہے ہوں تو ۔

کیا یہ ذیلی ڈائرکٹریز کی نگرانی کرتا ہے؟

نہیں، آپ کو ہر ڈائرکٹری کی نگرانی شامل کرنی ہوگی جو آپ نگرانی کرنا چاہتے ہیں۔ (چھپی نگرانی کے لئے منصوبہ بنایا گیا ہے: #18)۔

کیا مجھے گوروٹین میں ایک ساتھ خرابی اور واقعہ چینلوں کی نگرانی کرنی ہوگی؟

جی ہاں۔ آپ select کا استعمال کرکے دونوں چینلز سے ایک ہی گوروٹین سے پڑھ سکتے ہیں (آپ کو ہر چینل کے لئے علیحدہ سے گوروٹین نہیں چلانی چاہیے؛ مثال دیکھیں)۔

کیوں نوٹیفکیشنز NFS، SMB، FUSE، /proc، یا /sys پر کام نہیں کرتے ہیں؟

fsnotify کو فنکشن کرنے کے لئے موجودہ آپریٹنگ سسٹم کی حمایت کی ضرورت ہوتی ہے۔ موجودہ NFS اور SMB پروٹوکولز نیٹ ورک سطح پر فائل نوٹیفکیشن کی حمایت فراہم نہیں کرتے ہیں، اور /proc اور /sys ورچوئل فائل سسٹم بھی حمایت فراہم نہیں کرتے۔

اس کو ایک پولنگ واچر سے ٹھیک کیا جاسکتا ہے (#9)، لیکن اسے اب تک نہیں لگایا گیا ہے۔

میں کیوں بہت سی Chmod واقعات موصول کر رہا ہوں؟

کچھ پروگرام ممکن ہے کہ بہت سارے خصوصیت کے تبدیل ہوتے ہیں، مثال کے طور پر macOS پر اسپاٹ لائٹ، مضافت کے پروگرام، بیک اپ اےپلیکیشنز، اور کچھ دوسرے معروف اپلیکیشنز۔ عام طور پر، Chmod واقعات کو نظرانداز کرنا عموماً بہترین عمل ہوتا ہے کیونکہ یہ عام طور پر بے کار ہوتے ہیں اور مسائل پیدا کرسکتے ہیں۔

macOS پر اسپاٹ لائٹ انڈیکسنگ ممکن ہے کہ بہت سے واقعات پیدا کرے (دیکھیں #15)۔ موقت حل یہ ہے کہ آپ اپنی فولڈر کو Spotlight Privacy Settings میں شامل کریں جب تک ہمارے پاس ایک مقامی FSEvents منصوبہ نہ ہو (دیکھیں #11)۔

فائلوں کے دیکھ بھال میں مسائل واقع ہوتے ہیں

عام طور پر انفرادی فائلوں کی نگرانی کرنا (فولڈرز کی بجائے) مشورہ نہیں دیا گیا ہے کیونکہ بہت سے پروگرام، خاص طور پر ایڈیٹرز، انفرادی فائلز کو اتمک طور پر اپ ڈیٹ کریں گے: یہ ایک عارضی فائل میں لکھے گا اور پھر اسے ہدف مقام پر منتقل کرے گا، اصل فائل (یا اس کا کوئی مخصوص ویرایئنٹ) کو تبدیل کرتے ہوئے۔ اصل فائل پر نگرانی محو ہوگئی ہے۔

نتیجتاً، بجلی کا فیلر یا ٹکراو کا نتیجہ یہ ہوگا کہ ناکام ۔۔۔ظاہر نہیں ہوگا۔

والدین ڈائرکٹری کا دیکھ بھال کریں اور Event.Name کا استعمال کریں تاکہ آپ دلچسپی نہ رکنے والی فائلوں کو فلٹر کریں۔ cmd/fsnotify/file.go میں ایک مثال ہے۔

خصوصی پلیٹ فارم کے لئے نوٹس

لینکس

جب فائل حذف ہوتی ہے، تب تک سارے فائل ڈیسکرپٹرس بند نہیں ہوجاتے، ریموو واقعہ جاری نہیں ہوگا؛ اس وقت، ایک CHMOD واقعہ جاری ہوگا:

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

یہ واقعہ inotify کے ذریعے بھیجا ہے، لہذا اس پر زیادہ تبدیلیاں نہیں کرنی چاہیں۔

fs.inotify.max_user_watches سسٹیل متغیر ہر صارف کی زیادہ سے زیادہ واچز کی تعداد کو مختص کرتا ہے، اور fs.inotify.max_user_instances ہر صارف کی زیادہ سے زیادہ inotify انسٹینسز کی تعداد کو مختص کرتا ہے۔ آپ جو Watcher بناتے ہیں، وہ ایک "انسٹینس" ہے، اور آپ جو راستہ جوڑتے ہیں، وہ ایک "واچ" ہے۔

آپ انہیں /proc میں بھی تلاش کرسکتے ہیں، راستہ /proc/sys/fs/inotify/max_user_watches اور /proc/sys/fs/inotify/max_user_instances کی طرف۔

ان کو بڑھانے کے لئے، آپ sysctl کا استعمال کرسکتے ہیں یا proc فائل میں ان قدرتیوں کی قیمتیں لکھ سکتے ہیں:

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

ترتیبات کو دوبارہ چلانے کے لئے، /etc/sysctl.conf یا /usr/lib/sysctl.d/50-default.conf میں ترتیبات لکھیں (ہر لینکس تقسیم کی تفصیلات مختلف ہوسکتی ہیں، براہ کرم اپنی تقسیم کی دستاویزات کا حوالہ دیکھیں)۔

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

حد تک پہنچنے سے "No space left on device" یا "Too many open files" کے اخراجات ہوں گے۔

kqueue (macOS، تمام BSD سسٹم)

kqueue کو ہر نگرانی فائل کے لئے ایک فائل ڈسکرپٹر کھولنا ضروری ہوتا ہے؛ لہذا، اگر آپ پانچ فائلز شامل کرنے والے فولڈر کی نگرانی کر رہے ہیں، تو یہ چھ فائل ڈسکرپٹرز ہے۔ ان پلیٹ فارمز پر، آپ جلدی ہی سسٹم کی "زیادہ کھلی فائلیں" حد تک پہنچ جائیں گے۔