أنتج ZimaOS 1.6.2 عرضين مختلفين تمامًا على الأقل في تطبيق الملفات، ولا ينبغي تشخيصهما على أنهما خطأ واحد. كان أحدهما تراجعًا قابلًا لإعادة الإنتاج أثناء النقل، حيث نُقلت المحتويات لكن ظل مجلد المصدر فارغًا. أما الآخر فتعلق بأخطاء تثبيت محرك سحابي وتفويضه، وقد اختفت هذه الأخطاء في حالة موثقة بعد إجراء تحديث قسري للمتصفح.
يتضمن تراجع نقل المجلدات حدًا مهمًا يتعلق بالإصدار الحالي: فقد أصلح ZimaOS 1.7.1 صراحةً مشكلة بقاء المجلد الفارغ بعد القص. إذا كنت تستخدم إصدارًا مستقرًا حاليًا ولا تزال ترى العرض نفسه، فتحقق أولًا من الإصدار الدقيق قبل تطبيق حلول 1.6.2 القديمة.
المشكلة 1: بقاء مجلدات المصدر الفارغة بعد النقل
كان النمط المُبلغ عنه محددًا على نحو غير معتاد: نُقلت الملفات والمجلدات الفرعية بنجاح بين محركي SATA داخليين بنظام ext4، لكن ظل المجلد الأصلي الأعلى مستوى فارغًا. ولم تُظهر عمليات النسخ المشكلة، كما بدأ السلوك بعد التحديث إلى الإصدار 1.6.2.
كيفية التأكد من أن لديك الخطأ نفسه
- أنشئ مجلد اختبار صغيرًا يحتوي على مجلد فرعي وعدة ملفات.
- انقله بين موقعي تخزين محليين باستخدام تطبيق ملفات ZimaOS.
- تأكد من وصول جميع المحتويات إلى الوجهة.
- تحقق مما إذا كان المجلد الأب الفارغ فقط هو الذي بقي في المصدر.
إذا كانت الملفات مفقودة، أو تغيرت الأذونات، أو كانت الوجهة مشاركة شبكية بدلًا من تخزين ext4 محلي، فأنت تتعامل مع مسار مختلف، ولا ينبغي افتراض أن هذا التراجع التاريخي هو السبب.
تم إصلاح تراجع نقل المجلدات في ZimaOS 1.7.1
تسرد ملاحظات إصدار ZimaOS 1.7.1 صراحةً إصلاحًا لمشكلة بقاء المجلدات الفارغة بعد قص المجلدات في حالات معينة.
وهذا يعني أن أفضل حل لنظام لا يزال يعمل بالإصدار 1.6.2 هو التحديث إلى إصدار مستقر حالي بعد إنشاء نسخة احتياطية، وليس إنشاء برامج نصية تحذف المجلدات المتبقية تلقائيًا.
المشكلة 2: يعرض محرك التخزين السحابي أن التخزين غير موصول أو يعرض أخطاء المثيل
قد تحدث أخطاء محركات التخزين السحابية على عدة مستويات: تفويض موفر الخدمة السحابية، أو الرمز المحفوظ في ZimaOS، أو تثبيت الواجهة الخلفية، أو حالة واجهة المتصفح. تبدو لقطات الشاشة أعلاه خطيرة، لكن أحد المستخدمين في موضوع الإعلان تمكن من استعادة الخدمة بإجراء تحديث قسري للصفحة، كما اقترحت IceWhale.
الخطوة 1: أجرِ تحديثًا قسريًا لصفحة ZimaOS
قد تعيد عملية إعادة التحميل العادية استخدام JavaScript قديم وبيانات جلسة مخزنة مؤقتًا. استخدم طريقة التحديث القسري الخاصة بالمتصفح، ثم أعد فتح تطبيق الملفات وتحقق مما إذا كان الحساب السحابي لا يزال مدرجًا.
الخطوة 2: تحقق مما إذا كان موفر الخدمة مدعومًا حاليًا
يوثق دليل محركات التخزين السحابية في ZimaOS التكامل المباشر مع تطبيق الملفات لخدمات Google Drive وDropbox وOneDrive، مع عرض الواجهة الحالية لموفري الخدمة المدعومين.
الخطوة 3: أعد التفويض فقط إذا كانت الجلسة معطلة فعلًا
إذا ظل محرك التخزين غير متاح بعد التحديث القسري، فأزل الحساب وأعد توصيله فقط بعد التأكد من فهمك للمهام المحلية التي تعتمد على عملية التثبيت هذه. لا ينبغي أن تكون إعادة التفويض الاستجابة الأولى لمشكلة عرض فقط.
كيفية التمييز بين مشكلة ذاكرة التخزين المؤقت لواجهة المستخدم ومشكلة تثبيت فعلية
عادةً ما تتغير مشكلة واجهة المستخدم بعد التحديث القسري، أو عند استخدام متصفح آخر، أو عند فتح جلسة خاصة جديدة. أما مشكلة التثبيت في الواجهة الخلفية فتستمر عبر المتصفحات، وقد تؤثر أيضًا في مهام النسخ الاحتياطي أو مسارات التطبيقات التي تستخدم التثبيت السحابي.
استخدم هذا التمييز قبل حذف بيانات الاعتماد. إذا بدا تطبيق الملفات معطلًا في متصفح واحد لكنه يعمل في متصفح آخر، فركز على جلسة الواجهة الأمامية. أما إذا رأى كل عميل وخدمة التخزين المفقود نفسه، فتحقق من طبقة التثبيت أو التفويض.
لا تخلط بين أخطاء نقل الملفات المحلية وأخطاء مصادقة التخزين السحابي
جمع إعلان الإصدار 1.6.2 العديد من تقارير التحديث غير المرتبطة ببعضها. ومن السهل تحويل ذلك الموضوع إلى مقال عام عن «أخطاء التخزين»، لكن هذا يجعل استكشاف الأخطاء وإصلاحها أكثر صعوبة. فسلوك قص الملفات المحلية على ext4 وأخطاء OAuth أو تثبيت التخزين السحابي لها أدلة مختلفة، ونقاط فشل مختلفة، وإصلاحات مختلفة.
يوفر موجز التكامل السحابي سياقًا أوسع لسير عمل التخزين السحابي والمحلي.
ما ينبغي فعله إذا استمرت المشكلة في إصدار ZimaOS الحالي
بالنسبة إلى مشكلة المجلدات، سجّل إصدار ZimaOS الحالي، ونظام الملفات في المصدر والوجهة، وما إذا كان كلاهما محليًا، وما إذا كانت العملية قصًا أو نقلًا أم نسخًا. وبالنسبة إلى المشكلة السحابية، سجّل موفر الخدمة، والمتصفح، والخطأ الدقيق، وما إذا كان التحديث القسري يغيره، وما إذا كان محرك التخزين يعمل من عميل آخر.
يساعد ذلك على جعل تقرير الخطأ الجديد مفيدًا بدلًا من افتراض عودة عيب قديم من الإصدار 1.6.2.
الأسئلة الشائعة
هل يصلح ZimaOS 1.7.1 مشكلة بقاء مجلد فارغ بعد نقل الملفات؟
نعم. تذكر ملاحظات إصدار 1.7.1 صراحةً إصلاح مشكلة المجلدات الفارغة التي قد تبقى بعد قص المجلدات في حالات معينة.
هل ينبغي أن أحذف المجلدات الفارغة يدويًا في الإصدار 1.6.2؟
يمكنك إزالة البقايا الفارغة المؤكدة، لكن التحديث هو الحل الأفضل على المدى الطويل. لا تؤتمت الحذف حتى تتحقق من عدم فشل نقل أي ملفات.
لماذا يمكن أن يؤدي التحديث القسري إلى إصلاح خطأ في محرك التخزين السحابي؟
قد يحتفظ المتصفح بحالة قديمة للواجهة الأمامية أو ببيانات جلسة قديمة بعد التحديث. فإذا كانت عملية التثبيت في الواجهة الخلفية سليمة، يمكن أن تؤدي إعادة تحميل أصول الواجهة الأمامية والجلسة إلى استعادة واجهة المستخدم دون تغيير الحساب.
هل ينبغي أن أفصل OneDrive أو Google Drive وأعيد توصيله فورًا؟
لا. جرّب أولًا إجراء تحديث قسري وفتح جلسة متصفح نظيفة أخرى. أعد التفويض فقط عندما يكون التثبيت أو الرمز غير صالح فعلًا.
