تظهر تعارضات أسماء الملفات التي تختلف فقط في حالة الأحرف أثناء استعادة NAS عبر الأنظمة عندما تحتوي النسخة الاحتياطية على مسارين يعتبرهما وجهة الاستعادة متكافئين. قد يحافظ خادم Linux المنزلي على Photo.jpg و photo.jpg كملفات منفصلة، بينما قد يعامل حجم Windows أو حجم macOS الافتراضي أو عميل SMB تلك الأسماء كوجهة واحدة. عندها يتعين على أداة الاستعادة الكتابة فوق، أو إعادة التسمية، أو التخطي، أو الدمج، أو التوقف.
لا تتابع الاستعادة الكاملة حتى تعرف أي المسارات تصادمت وكيف تعاملت الأداة معها. استعد الشجرة المتأثرة في موقع عزل مؤقت، واحتفظ بكلا الكائنين المصدرين تحت أسماء مؤقتة حتمية، وأنشئ سجل تعيين المسارات قبل نقل البيانات إلى مشاركة NAS الحية.
لماذا يمكن للنسخة الاحتياطية تخزين اسمين يرفضهما هدف الاستعادة؟
يمكن لمستودع النسخ الاحتياطي تسجيل المسارات كأسماء غير شفافة دون فرض قواعد المقارنة لنظام الملفات الوجهة. تميز أنظمة ملفات Linux عادة بين الأحرف الكبيرة والصغيرة، بينما تحافظ أنظمة ملفات Windows وmacOS الافتراضية عادة على حالة الأحرف المكتوبة لكنها تقارن الأسماء بدون تمييز حالة الأحرف. توضح مناقشة الاستعادة عبر الأنظمة الأساسية أن مسارات المصدر قد تكون صالحة في النسخة الاحتياطية لكنها غير قابلة للتمثيل على نظام الاستعادة.
بالنسبة لـ NAS منزلي، يحدث هذا غالبًا بعد استعادة حجم حاوية Linux، أو دليل المطور، أو شجرة استيراد الصور، أو مكتبة الوسائط إلى مشاركة سيتم الوصول إليها من Windows أو macOS. النسخة الاحتياطية ليست بالضرورة تالفة؛ مساحة الأسماء الوجهة تحتوي على مجموعة أصغر من الأسماء المميزة.
SMB الذي يحافظ على حالة الأحرف ليس هو نفسه التخزين الحساس لحالة الأحرف
قد يعرض مشاركة SMB الكتابة الأصلية للأحرف الكبيرة والصغيرة ولا يزال يؤدي البحث بدون تمييز حالة الأحرف. يصف مثال من مجتمع TrueNAS قواعد حالة مختلفة في طبقات مجموعة البيانات والوصول عبر SMB. لذلك قد يخزن الخادم أسماء مختلطة الحالة محليًا بينما لا يمكن لعميل SMB على Windows أو macOS معالجتها ككائنات منفصلة.
اختبر مسار الاستعادة الفعلي، وليس فقط إعداد نظام ملفات NAS. أنشئ ملفين غير ضارين تختلف أسماؤهما فقط في الحالة من خلال نفس العميل، البروتوكول، التركيب، ودليل الوجهة الذي سيستخدمه عمل الاستعادة. إذا فشل الإنشاء الثاني أو تم حله إلى الملف الأول، فلا يمكن لذلك المسار استقبال الشجرة الأصلية بأمان دون تغيير.
تصادم اسم مجلد يمكن أن يدمج شجرة فرعية كاملة
قد يحدث التعارض في أي مكون من مكونات الدليل، وليس فقط اسم الملف النهائي. إذا كانت النسخة الاحتياطية تحتوي على Photos/2025/A.jpg وphotos/2025/B.jpg، قد يدمج وجهة غير حساسة للحالة كلا الفرعين في مجلد واحد أو ترفض الفرع الثاني. يوضح حساب نقل مختلط بين لينكس وويندوز كيف يمكن أن تصادمات مكونات الدليل تسبب توجيهًا خاطئًا أو فقدانًا للملفات.
قارن المسارات النسبية الكاملة بعد تطبيق قواعد طي الحالة للوجهة. تقرير يفحص فقط أسماء القواعد المكررة قد يفوت التصادمات التي تنشأ من مجلدات الأب.
أدوات الاستعادة لا تتعامل مع كل تصادم بأمان
قد تتوقف تطبيقات الاستعادة بخطأ "موجود بالفعل"، تضيف لاحقة، تحتفظ بالملف الأول، تحتفظ بالملف الأخير، أو تدمج أشجار الدليل. بعض العمليات تنتهي بحالة نجاح أو تحذير رغم تخطي أحد أعضاء زوج التصادم. تظهر الأبحاث في التعامل غير المتسق مع تصادمات حساسية الحالة سبب ضرورة مراقبة سلوك الأداة بدلاً من افتراضه.
قبل استعادة كبيرة، أنشئ نسخة احتياطية اختبارية صغيرة تحتوي على أزواج من الملفات والمجلدات تختلف فقط في الحالة. سجّل ما إذا كانت الأداة تفشل، تعيد التسمية، تستبدل، أو تدمج، وتحقق من تجزئة المحتوى لكليهما بعد ذلك.
يمكن أن ينتج عن تطبيع يونيكود تصادم مشابه
يمكن أن تبدو اسماء ملفين متطابقة بينما تستخدم تسلسلات نقاط رمز يونيكود مختلفة، مثل حرف مركب مسبقًا مع علامة مضافة. يحافظ نظام APFS على الأشكال أثناء استخدام مقارنات مُطَبَّعَة في بعض الأوضاع، وتتفاعل حساسية الحالة وتطبيع يونيكود في البحث عن أسماء الملفات.
لا تفترض أن كل تعارض ظاهر بسبب حالة الأحرف فقط ناجم عن الحروف الكبيرة والصغيرة. صدر الأسماء بتنسيق مهرب أو مدرك لنقاط الترميز عند التعامل مع الأسماء المشددة، أو أسماء اللغات الآسيوية، أو الأسماء المتطابقة بصريًا.
تجميد الاستعادة والحفاظ على كلا الكائنين أولاً
عند ظهور تصادم، توقف عن الاستعادة إلى الوجهة الحية. لا تعيد تشغيل نفس المهمة مع تمكين الكتابة فوق بشكل متكرر، لأن الفائز قد يتغير حسب ترتيب التصفح. أنشئ نظام ملفات تجميع حساس لحالة الأحرف أو استعد عبر بيئة لينكس التي يمكنها تمثيل الاسمين. تشرح مقالة سطر أوامر ويندوز أن الدلائل الحساسة لحالة الأحرف يمكنها الحفاظ على الأسماء التي لا تستطيع تطبيقات ويندوز العادية تمييزها، مما يوضح سبب ضرورة استخدام مساحة أسماء يمكنها تمثيل كلا الكائنين أثناء التجميع.
استعد كل كائن متصادم إلى اسم مؤقت فريد مثل Photo.jpg.__case1 و photo.jpg.__case2احتفظ بالمسار الأصلي، وإصدار النسخة الاحتياطية، والحجم، ومجموع التحقق، والاسم المؤقت المختار في ملف تعيين CSV أو JSON.
إعادة تسمية التصادمات بشكل حتمي قبل نقلها إلى المشاركة الحية
اختر قاعدة لا تعتمد أبدًا على الملف الذي يتم مواجهته أولاً. أضف تسمية منصة المصدر، أو جزء تجزئة ثابت، أو تسلسل صريح مع الحفاظ على الامتداد. على سبيل المثال، احتفظ بـ Photo__linux_A1B2.jpg و photo__linux_C3D4.jpg بدلاً من قبول لاحقات "نسخ" التلقائية التي يكون معناها غير واضح.
راجع التعيين قبل تغيير الأسماء في مستودع النسخ الاحتياطي أو المصدر الأصلي. يمكن استخدام دليل ZimaSpace لـكشف تصادمات أسماء الملفات الحساسة لحالة الأحرف قبل النسخ عبر الأنظمة لفحص شجرة التجميع المعاد بناؤها والتأكد من عدم وجود أزواج غير محلولة.
إصلاح مراجع التطبيق بعد إعادة تسمية الملفات
قد يختفي ملف وسائط معاد تسميته من قاعدة بيانات المكتبة، قد يشير تكوين الحاوية إلى المسار القديم، وقد يعامل تطبيق الصور الكائن المعاد تسميته كأصل جديد. استعد البيانات أولاً، ثم حدّث قوائم التشغيل، روابط الجوانب، السكريبتات، سجلات قاعدة البيانات، تركيبات الربط، وفهارس التطبيقات التي تعتمد على التهجئة الدقيقة.
للتطبيقات المستضافة ذاتيًا، احتفظ بقاعدة البيانات والتكوين الذي يصف المسارات الأصلية. يمكن لاستعادة نظام الملفات فقط الاحتفاظ بكل بايت لكنها قد تترك التطبيق غير مكتمل عندما لا تتطابق مراجع المسار.
استخدم تقرير التصادم لتحديد إجراء الاسترداد
| النتيجة الملحوظة | السبب المحتمل | إجراء استرداد آمن |
|---|---|---|
| الملف الثاني يبلغ "موجود بالفعل" | الوجهة تقارن الأسماء بدون حساسية للحالة | استعد كلاهما إلى منطقة تحضيرية حساسة للحالة وأعد التسمية بشكل حتمي |
| مجلدان مصدر يظهران كمجلد واحد | دليل أب يختلف فقط في الحالة | قارن المسارات الكاملة المطبعّة وقم بتقسيم الشجرة المدمجة |
| تكتمل الاستعادة لكن عدد الكائنات أقل | تخطى الأداة أو استبدل أحد أعضاء التصادم | راجع سجلات التصادم وقارن جرد المسارات بالإضافة إلى المجاميع |
| الأسماء تبدو متطابقة لكن الاختلاف في الحالة غائب | تطبيع يونيكود أو أحرف غير مدعومة | افحص نقاط الشيفرة المهربة وطبعها من خلال التحضير |
| الملفات موجودة لكن التطبيق لا يمكنه العثور عليها | إعادة التسمية كسرت مراجع المسار الدقيقة | تحديث بيانات تعريف التطبيق، الفهارس، وتركيبات الحاويات |
الأسئلة الشائعة
هل يمكن لمشاركة SMB الحفاظ على كلاهما File.txt و file.txt?
فقط عندما يستخدم مجموعة البيانات الأساسية، تكوين خادم SMB، العميل، والتطبيق جميعها دلالات حساسة للحالة متوافقة. مجموعة بيانات NAS حساسة للحالة وحدها لا تثبت أن كل عميل SMB يمكنه إنشاء ومعالجة كلا الاسمين.
هل تحل الاستعادة إلى وحدة APFS حساسة للحالة كل تعارض؟
لا. يمكنه الحفاظ على أزواج تختلف فقط في الحالة، لكن وجهة SMB اللاحقة، عميل Windows، التطبيق، تنسيق الأرشيف، أو قواعد مقارنة يونيكود قد تدمج أو ترفض الأسماء.
لماذا يمكن لاسمين ملفين متطابقين بصريًا أن يتعارضا؟
قد تستخدم تسلسلات يونيكود مختلفة تقوم الوجهة بتطبيعها إلى نفس الشكل للمقارنة. افحص نقاط الشيفرة بدلاً من الاعتماد فقط على كيفية عرض Finder أو Explorer للاسم.
النتيجة النهائية
تحدث تصادمات أسماء الملفات التي تختلف فقط في حالة الأحرف لأن النسخة الاحتياطية يمكن أن تحافظ على أسماء مسارات مميزة أكثر مما يمكن لوجهة الاستعادة عبر الأنظمة تمثيله. توقف عند أول تصادم، استعد إلى منطقة تحضيرية متوافقة، احتفظ بكل كائن بأسماء مؤقتة حتمية، سجل خريطة، وتحقق من العدود والمجاميع قبل استيراد البيانات إلى مشاركة NAS المنزلية الحية.
الدعم والنصائح
المزيد للقراءة

هل يمكن لـ Plex مشاركة وحدة معالجة الرسومات (GPU) مع حاوية Docker أخرى؟
يمكن لـ Plex وحاوية أخرى غالبًا الوصول إلى وحدة معالجة الرسومات نفسها، لكن يجب اختبار دعم برنامج التشغيل، وتعيين الجهاز، وحِمل محرّك الفيديو، والذاكرة،...

كيفية معرفة ما إذا كان خطأ Plex ناتجًا عن العميل أم الخادم
أعِد إنتاج العنصر نفسه على عميل آخر، وقارن مسار الجلسة، ثم اجمع أدلة من الخادم فقط بعد أن يحدد النطاق موضع الفشل الفعلي.

كيفية إعداد ذاكرة التخزين المؤقت وموقع التخزين المؤقت لتحويل الترميز في Plex
احمِ حالة Plex الدائمة مع وضع الملفات المؤقتة للتحويل على مساحة تخزين محلية مناسبة، ثم تحقّق من التنظيف والمساحة الحرة وسلوك إعادة التشغيل.

