fsnotify
হল একটি Go দ্বারা লেখা ফাইল সিস্টেম বিজ্ঞপ্তি লাইব্রেরি, যা ফাইল সিস্টেমে ফাইল এবং নির্দেশিকা পরিবর্তন মনিটর করে এবং পরিবর্তন ঘটলে অ্যাপ্লিকেশনকে বিজ্ঞপ্তি প্রেরণ করে। এটি প্ল্যাটফর্ম অব্যাহত সমর্থন করে এবং Linux, macOS, এবং Windows সহ বিভিন্ন অপারেটিং সিস্টেমে চালানো যায়। fsnotify
বিভিন্ন অপারেটিং সিস্টেমের ফাইল সিস্টেম বিজ্ঞপ্তি মেকানিজম ব্যবহার করে, যেমন লিনাক্সে ইনোটিফাই, macOS এ FSEvents, এবং উইন্ডোজে ReadDirectoryChangesW।
Go 1.17 বা পরবর্তী সংস্করণ ব্যবহার করা প্রয়োজন; সম্পূর্ণ নথি এখানে পাওয়া যাবে: https://pkg.go.dev/github.com/fsnotify/fsnotify
বিভিন্ন অপারেটিং সিস্টেমের সমর্থন:
ব্যাকএন্ড | অপারেটিং সিস্টেম | স্থিতি |
---|---|---|
ইনোটিফাই | লিনাক্স | সমর্থিত |
কিউই | বিএসডি, macOS | সমর্থিত |
ReadDirectoryChangesW | উইন্ডোজ | সমর্থিত |
FEN | ইউমিলোস | সমর্থিত |
fanotify | লিনাক্স 5.9+ | এখনো সমর্থিত নয় |
AHAFS | এআইএক্স | AIX শাখা; পরীক্ষামূলক বৈশিষ্ট্য মেয়াদশেষ এবং পরীক্ষার পরিবেশ অভাব কারণে |
FSEvents | macOS | x/sys/unix সমর্থনের প্রয়োজন |
USN জার্নাল | উইন্ডোজ | x/sys/windows সমর্থনের প্রয়োজন |
পোলিং | সব | এখনো সমর্থিত নয় |
এবংরয় Android এবং Solaris, যা লিনাক্স এবং ইউমিলোস অন্তর্ভুক্ত থাকা উচিত, এখনো পরীক্ষা করা হয় নাই।
ব্যবহারের উপায়
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)
if event.Has(fsnotify.Write) {
log.Println("সম্পাদিত ফাইল:", event.Name)
}
case err, ok := <-watcher.Errors:
if !ok {
return
}
log.Println("ত্রুটি:", 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 ইভেন্ট পেয়েছি?
কিছু কার্যক্রম বহুত বেশি বৈশিষ্ট্য পরিবর্তন উৎপন্ন করতে পারে, যেমন macOS-এ Spotlight, অ্যান্টিভাইরাস প্রোগ্রাম, ব্যাকআপ অ্যাপ্লিকেশন, এবং কিছু অন্যান্য পরিচিত অ্যাপ্লিকেশন। সাধারণভাবে, Chmod ইভেন্টগুলি প্রায়ই অকার্যকর হয় এবং সমস্যা সৃষ্টি করতে পারে, তাই অবশ্যই সাধারণভাবে এগুলি অগ্রাহ্য করা হয়।
macOS-এ Spotlight ইনডেক্সিং কয়েকটি ইভেন্ট জন্য কারণ হতে পারে (দেখুন #15)। একটি অস্থায়ী সমাধান হ'ল আপনার ফোল্ডারগুলিকে Spotlight Privacy Settings এ যোগ করা পর্যন্ত একটি প্রাকৃতিক FSEvents অনুমোদন হবে (দেখুন #11)।
ফাইল মনিটরিং ভালো ভাবে কাজ করে না
সাধারণভাবে সিফার বেশি পরামর্শিত নয় (পাল্লা না মানে আলাদা করে যদি না ডিরেক্টরিগুলি) কারণ অনেক প্রোগ্রাম, সপ্তাহরা, ফাইলগুলি সপ্তাহরা আপডেট করবে: এটি একটি অস্থায়ী ফাইলে লিখবে এবং তারপরে এটি লক্ষ্যমান অবস্থানে সরাবে, মূল ফাইলটি (বা এর কোনও পরিবর্তন) ওভাররাইট করার জন্য মূল ফাইলে এটি লিখবে। মনিটরে মূল ফাইলটি এখনই হারিয়ে গেছে কারণ ফাইলটি বিদ্যমান নেই।
ফলে, বিদ্যুৎ বিচলনা বা একটি ক্র্যাশ হবে না কোনও অধূত ফাইলে।
মাত্র লেনার ডিরেক্টরি মনিটর করুন এবং Event.Name
ব্যবহার করুন যে ফাইলগুলি আপনি আগ্রহী না তাদের বাদ দেয়ার জন্য। cmd/fsnotify/file.go
একটি উদাহরণ রয়েছে।
বিশেষ প্ল্যাটফর্মের জন্য নোট
লিনাক্স
যখন একটি ফাইল মুছে ফেলা হয়, তবে রিমুভ ইভেন্ট যত্নশীল না হওয়া পর্যন্ত সমস্ত ফাইল ডেসক্রিপ্টর বন্ধ করা না হওয়া পর্যন্ত; এই সময়ে, একটি চেমোড ইভেন্ট অবস্থা রিপোর্ট হবেঃ
fp := os.Open("file")
os.Remove("file") // CHMOD
fp.Close() // REMOVE
এটি inotify দ্বারা প্রেরিত ইভেন্ট, তাই এর সাথে অধিকাংশ পরিবর্তন করা না উচিত।
fs.inotify.max_user_watches
সিসটেম চিত্র সঙ্গে একটি প্রতিত্যাশিত দেখা দেয় প্রতি ব্যবহারকারীর জন্য সর্বোচ্চ নম্বর দেখা দেয়, এবং fs.inotify.max_user_instances
সর্বোচ্চ ব্যবহারকারীর জন্য সর্বোচ্চ সংখ্যার ইনোটিফাই ইনস্ট্যান্স দেখা দেয়। আপনি যেকোনো 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
এডিট করুন ("No space left on device" or "Too many open files" ভুল আসবে।
kqueue (macOS, সমস্ত BSD সিস্টেম)
kqueue একটি প্রতিদর্শিত ফাইল বর্ণনা করার জন্য একটি ফাইল ডেসক্রিপ্টর খোলার প্রয়োজন করে; অতএব, যদি আপনি একটি ফোল্ডার পর্যবেক্ষণ করছেন যা পাঁচটি ফাইল অবজার্ভ করে, তাহলে এটির মাধ্যমে সিস্টেমের "সর্বোচ্চ খোলা ফাইল" সীমা দ্রুত পৌঁছাতে পারেন।
আপনি প্রতিটি বন্ধুত্বের সর্বাধিক সংখ্যা নিয়ন্ত্রণ করার জন্য সিসটেমের kern.maxfiles
এবং kern.maxfilesperproc
সিসটেমের মাধ্যমে ব্যবহার করতে পারেন।