فحص سلامة المرفقات
عندما يختفي ملف المرفق ولكن يبقى صف قاعدة البيانات الخاص به، لا يزال XenForo يعرض رابط المرفق. عند النقر عليه يظهر خطأ 500 ويمتلئ سجل الأخطاء بالرسالة التالية:
لا توجد طريقة مدمجة للعثور على هذه المرفقات بشكل جماعي، ولا توجد طريقة لتمييز مرفق مفقود فعلاً عن مرفق لا يزال ملفه موجوداً في التخزين تحت مفتاح قديم.
يحدث هذا بعد استعادة قاعدة بيانات، أو ترحيل تخزين، أو مزامنة فاشلة مع S3/R2، أو نسخة احتياطية مستعادة جزئياً، أو ببساطة بعد سنوات من عمليات الحذف الفاشلة المتراكمة.
ما الذي يفعله الأداة
يتم تصنيف كل مرفق إلى واحد من ثلاثة أنواع:
فحص md5 هذا مهم. إعادة الربط بناءً على اسم الملف فقط قد يؤدي إلى تثبيت لقطة شاشة تخص شخصاً غريباً داخل مشاركة شخص آخر.
ثلاثة أوضاع
Scan (فحص) — يتنقل عبر قاعدة البيانات سائلاً "أين الملف؟" ويكتب ملف CSV. للقراءة فقط.
Orphans (اليتامى) — العكس. يتنقل عبر التخزين سائلاً "أي صف يملك هذا الملف؟"، ليجد ملفات تقطعت بسبب تراجع قاعدة بيانات لا يمكن للفحص العادي رؤيتها، لأن تلك الصفوف لم تعد موجودة. للقراءة فقط.
Apply (تطبيق) — يستهلك ملف CSV الخاص بالفحص، ويعيد التحقق من كل صف مقابل التخزين مرة أخرى، ثم يصلح. لا يحذف إلا إذا طلبت ذلك صراحة.
الاستخدام
ضع السكربت في جذر منتداك بجانب index.php. ثم:
هذا للقراءة فقط ولا يغيّر أي شيء. يقوم --index بعمل قائمة تتبعية واحدة لتخزينك ويجيب على كل استعلام من الذاكرة — على التخزين البعيد يحوّل ذلك حوالي 200,000 رحلة ذهاب وإياب شبكية إلى حوالي 200 استدعاء قائمة.
راجع ملف CSV. ثم قم بعمل نسخة احتياطية:
الإصلاح دون حذف أي شيء:
الإصلاح ومسح الصفوف الميتة:
الأمان
هذه الأداة يمكنها حذف صفوف من قاعدة البيانات، لذلك بُنيت على افتراض أنها قد تكون مخطئة.
الفحص لا يكتب أبداً. الحذف يتطلب تشغيلاً منفصلاً، وعلامة منفصلة، وملف CSV أتيحت لك فرصة قراءته.
يتم إعادة التحقق من كل صف مقابل التخزين الحي مباشرة قبل لمسه. لا يمكن لملف CSV قديم أو مُحرَّر يدوياً أن يسبب ضرراً.
إلغاء عند الفهرس الفارغ. إذا كان التخزين غير قابل للوصول أو كانت البادئة خاطئة، سيبدو كل صف MISSING. هذا خطأ فادح ولا تتجاوزه --force.
حارس النسبة. يتم رفض خطة تحذف أكثر من 20% من جميع المرفقات — هذا النمط يعني عطل تخزين وليس فقدان بيانات.
حارس العدد. --max-delete (الافتراضي 2000) يحظر الخطط الكبيرة غير المتوقعة.
تمر عمليات الحذف عبر طبقة الكيان، لذلك يتم الحفاظ على attach_count بواسطة معالج المرفقات الخاص بـ XenForo نفسه لكل نوع محتوى، بما في ذلك تلك الخاصة بالإضافات الأخرى.
يتم رفض الوسائط غير المعروفة بدلاً من تجاهلها بصمت.
لا يمكن كتابة التقارير إلى مسار يمكن الوصول إليه عبر الويب — فهي تسرد كل مرفق على منتداك. تذهب إلى internal_data/attachment-audit/.
يرفض العمل عبر HTTP.
ما لا تلمسه أبداً: لا يتم تعديل المشاركات والمواضيع.
عندما يختفي ملف المرفق ولكن يبقى صف قاعدة البيانات الخاص به، لا يزال XenForo يعرض رابط المرفق. عند النقر عليه يظهر خطأ 500 ويمتلئ سجل الأخطاء بالرسالة التالية:
League\Flysystem\FileNotFoundException: File not found at path: attachments/236/236888-0dcb....data
src/XF/Pub/View/Attachment/View.php:27لا توجد طريقة مدمجة للعثور على هذه المرفقات بشكل جماعي، ولا توجد طريقة لتمييز مرفق مفقود فعلاً عن مرفق لا يزال ملفه موجوداً في التخزين تحت مفتاح قديم.
يحدث هذا بعد استعادة قاعدة بيانات، أو ترحيل تخزين، أو مزامنة فاشلة مع S3/R2، أو نسخة احتياطية مستعادة جزئياً، أو ببساطة بعد سنوات من عمليات الحذف الفاشلة المتراكمة.
ما الذي يفعله الأداة
يتم تصنيف كل مرفق إلى واحد من ثلاثة أنواع:
- OK — الملف موجود بالضبط حيث يتوقعه XenForo.
- RELINK — الملف مفقود من مساره المتوقع، لكن يوجد ملف لهذا data_id تحت file_key مختلف و md5 الخاص به يطابق file_hash المخزّن. المرفق سليم؛ فقط مؤشر قاعدة البيانات قديم. قابل للإصلاح دون فقدان أي بيانات.
- MISSING — لا يوجد ملف على الإطلاق، أو يوجد مرشح لكن md5 الخاص به لا يتطابق، مما يعني أن المعرّف أُعيد استخدامه بواسطة رفع لاحق وهذا الملف يخص شخصاً آخر. لا شيء قابل للاسترداد.
فحص md5 هذا مهم. إعادة الربط بناءً على اسم الملف فقط قد يؤدي إلى تثبيت لقطة شاشة تخص شخصاً غريباً داخل مشاركة شخص آخر.
ثلاثة أوضاع
Scan (فحص) — يتنقل عبر قاعدة البيانات سائلاً "أين الملف؟" ويكتب ملف CSV. للقراءة فقط.
Orphans (اليتامى) — العكس. يتنقل عبر التخزين سائلاً "أي صف يملك هذا الملف؟"، ليجد ملفات تقطعت بسبب تراجع قاعدة بيانات لا يمكن للفحص العادي رؤيتها، لأن تلك الصفوف لم تعد موجودة. للقراءة فقط.
Apply (تطبيق) — يستهلك ملف CSV الخاص بالفحص، ويعيد التحقق من كل صف مقابل التخزين مرة أخرى، ثم يصلح. لا يحذف إلا إذا طلبت ذلك صراحة.
الاستخدام
ضع السكربت في جذر منتداك بجانب index.php. ثم:
هذا للقراءة فقط ولا يغيّر أي شيء. يقوم --index بعمل قائمة تتبعية واحدة لتخزينك ويجيب على كل استعلام من الذاكرة — على التخزين البعيد يحوّل ذلك حوالي 200,000 رحلة ذهاب وإياب شبكية إلى حوالي 200 استدعاء قائمة.
راجع ملف CSV. ثم قم بعمل نسخة احتياطية:
الإصلاح دون حذف أي شيء:
الإصلاح ومسح الصفوف الميتة:
الأمان
هذه الأداة يمكنها حذف صفوف من قاعدة البيانات، لذلك بُنيت على افتراض أنها قد تكون مخطئة.
الفحص لا يكتب أبداً. الحذف يتطلب تشغيلاً منفصلاً، وعلامة منفصلة، وملف CSV أتيحت لك فرصة قراءته.
يتم إعادة التحقق من كل صف مقابل التخزين الحي مباشرة قبل لمسه. لا يمكن لملف CSV قديم أو مُحرَّر يدوياً أن يسبب ضرراً.
إلغاء عند الفهرس الفارغ. إذا كان التخزين غير قابل للوصول أو كانت البادئة خاطئة، سيبدو كل صف MISSING. هذا خطأ فادح ولا تتجاوزه --force.
حارس النسبة. يتم رفض خطة تحذف أكثر من 20% من جميع المرفقات — هذا النمط يعني عطل تخزين وليس فقدان بيانات.
حارس العدد. --max-delete (الافتراضي 2000) يحظر الخطط الكبيرة غير المتوقعة.
تمر عمليات الحذف عبر طبقة الكيان، لذلك يتم الحفاظ على attach_count بواسطة معالج المرفقات الخاص بـ XenForo نفسه لكل نوع محتوى، بما في ذلك تلك الخاصة بالإضافات الأخرى.
يتم رفض الوسائط غير المعروفة بدلاً من تجاهلها بصمت.
لا يمكن كتابة التقارير إلى مسار يمكن الوصول إليه عبر الويب — فهي تسرد كل مرفق على منتداك. تذهب إلى internal_data/attachment-audit/.
يرفض العمل عبر HTTP.
ما لا تلمسه أبداً: لا يتم تعديل المشاركات والمواضيع.
