إينوتيفاي

يُعدّ inotify ( إشعار عقدة الملف ) نظامًا فرعيًا لنواة لينكس، أنشأه جون مكوتشان، وهو يراقب التغييرات التي تطرأ على نظام الملفات ، ويُبلغ التطبيقات بها. يُمكن استخدامه لتحديث طرق عرض الدلائل تلقائيًا، وإعادة تحميل ملفات التكوين، وتسجيل التغييرات، والنسخ الاحتياطي، والمزامنة، والتحميل. تسمح أوامر inotifywait و inotifywatch (التي يُشرف عليها إريك كورتين كجزء من مشروع inotify-tools) باستخدام نظام inotify الفرعي من سطر الأوامر. ^{[ 1 ]} يُستخدم بشكل أساسي في أدوات البحث المكتبية مثل Beagle، حيث تُتيح وظيفته إعادة فهرسة الملفات المُعدّلة دون الحاجة إلى فحص نظام الملفات بحثًا عن التغييرات كل بضع دقائق، وهو ما يُعدّ غير فعّال للغاية.

حلّت أداة inotify محلّ أداة dnotify السابقة ، التي كانت لها أهداف مماثلة. دُمجت inotify في نواة لينكس الرئيسية في الإصدار 2.6.13، الصادر في 29 أغسطس 2005؛ ^{[ 2 ]} وتضمنت الإصدارات اللاحقة من النواة تحسينات إضافية. أُضيفت واجهات المكتبة المطلوبة إلى مكتبة GNU C (glibc) في إصدارها 2.4، الصادر في مارس 2006، بينما اكتمل دعم inotify في إصدار glibc 2.5، الصادر في سبتمبر 2006. ^{[ 3 ]}

تشمل القيود التي يفرضها برنامج inotify ما يلي:

• لا يدعم Inotify مراقبة الدلائل بشكل متكرر، مما يعني أنه يجب إنشاء عملية مراقبة منفصلة لكل دليل فرعي. ^{[ 4 ]} في المقابل، يوفر الأمر inotifywait مراقبة الدلائل بشكل متكرر. ^{[ 5 ]}
• يقوم Inotify بالإبلاغ عن بعض الأحداث في sysfs و procfs وليس كلها .
• يتطلب الإخطار عبر inotify أن تكون النواة على دراية بجميع أحداث نظام الملفات ذات الصلة، وهو أمر ليس ممكنًا دائمًا لأنظمة الملفات الشبكية مثل NFS حيث لا يتم بث التغييرات التي يجريها عميل واحد على الفور إلى العملاء الآخرين.
• لا يتم التعامل مع أحداث إعادة التسمية بشكل مباشر؛ أي أن inotify يصدر حدثين منفصلين يجب فحصهما ومطابقتهما في سياق ظروف التنافس المحتملة.

• يوليو 2004: الإعلان الأول عن الإصدار ^{[ 6 ]}
• 29 أغسطس 2005: تم إصدار نواة لينكس الإصدار 2.6.13، والتي تحتوي على كود inotify المدمج ^{[ 2 ]}
• مارس 2006: تم إصدار مكتبة GNU C (glibc) الإصدار 2.4، مما أدى إلى توفير دعم inotify الأولي ^{[ 3 ]}
• سبتمبر 2006: تم إصدار الإصدار 2.5 من Glibc، والذي يوفر دعمًا كاملاً لـ inotify ^{[ 3 ]}

يُوفر استخدام inotify العديد من المزايا مقارنةً بواجهة برمجة التطبيقات dnotify القديمة التي حلّت محلها. ^{[ 7 ] [ 8 ] [ 9 ]} مع dnotify، كان على البرنامج استخدام مُعرّف ملف واحد لكل دليل يُراقبه. وقد يُصبح هذا الأمر عائقًا نظرًا لاحتمالية الوصول إلى الحد الأقصى لمُعرّفات الملفات لكل عملية. لاحقًا، تم تطوير fanotify للتغلب على هذه المشكلة. كما تبيّن أن استخدام مُعرّفات الملفات مع dnotify يُشكّل مشكلةً عند استخدام وسائط التخزين القابلة للإزالة، حيث لا يُمكن فصل الأجهزة لأن مُعرّفات الملفات تُبقي الموارد مشغولة.

من عيوب dnotify الأخرى مستوى التفصيل، إذ لا يستطيع المبرمجون مراقبة التغييرات إلا على مستوى الدليل. وللوصول إلى معلومات تفصيلية حول التغييرات البيئية التي تحدث عند إرسال رسالة إشعار، يجب استخدام بنية بيانات إحصائية (stat structure)؛ وهذا يُعدّ ضرورة لا مفر منها، إذ يتطلب الأمر الاحتفاظ بنسخة احتياطية من هذه البنية، حيث تُجرى مقارنة مع النسخة المخزنة لكل بنية بيانات إحصائية جديدة يتم إنشاؤها.

تستخدم واجهة برمجة تطبيقات inotify عددًا أقل من مُعرّفات الملفات، مما يسمح للمبرمجين باستخدام واجهة select و poll المُعتمدة، بدلاً من نظام إشعارات الإشارة الذي يستخدمه dnotify . وهذا يُسهّل أيضًا التكامل مع المكتبات الموجودة القائمة على select أو poll (مثل GLib ).

• مراقب تغيير الملفات (SGI)
• DMAPI
• kqueue (FreeBSD، NetBSD، OpenBSD، DragonFly BSD، و macOS)
• أحداث نظام التشغيل ماك (FSEvents)

• Kernel Korner – مقدمة إلى inotify بقلم روبرت لوف (2005) 
• مقال LWN حول Inotify - مراقبة أحداث نظام الملفات باستخدام Inotify (قديم جزئياً) 
• مقال من شركة IBM - مراقبة أحداث نظام ملفات Linux باستخدام inotify (6 سبتمبر 2008). 
• إشعار نظام الملفات، الجزء 1: نظرة عامة على dnotify و inotify - مقال من LWN.net بقلم مايكل كيريسك (2014)