بدأ المصدر بنظرية معقولة مفادها أن السبب هو بيانات AppData قديمة، لكن المنشور النهائي جعل هذا التفسير غير كافٍ. فقد تجاوزت التطبيقات التي أُزيلت سابقًا نموذج الإعداد وحاولت إعادة استخدام مسارات ربط غير موجودة، ما أدى إلى ظهور أخطاء Docker مثل bind source path does not exist. واقترح أحد أفراد المجتمع إزالة مجلد AppData القديم أو إعادة تسميته حتى يتعامل ZimaOS مع التطبيق باعتباره جديدًا.
ثم أفاد صاحب المنشور الأصلي بأن ذلك نجح مرة واحدة، لكنه لم يعد مفيدًا لاحقًا. والأهم من ذلك أن التطبيقات الجديدة التي يتم تثبيتها للمرة الأولى بدأت أيضًا بتجاوز نموذج الإعداد والتعطل عند نسبة 100%، بينما ظل تثبيت التطبيقات عبر YAML يعمل. وهذا ينقل موضع الاشتباه الأكبر من مجلد تطبيق واحد تالف إلى مسار واجهة متجر التطبيقات/إعداداته التاريخي نفسه.
كان خطأ Docker حقيقيًا، لكنه ناتج لاحقًا
بدا الفشل الظاهر على النحو التالي:
Error response from daemon:
invalid mount config for type "bind":
bind source path does not exist: [EXPECTED PATH]كان Docker يرفض بشكل صحيح نقطة ربط لا يوجد مجلد المصدر الخاص بها على المضيف. وكان السؤال الذي لم تتم الإجابة عنه هو: لماذا أنشأ متجر التطبيقات هذا المسار أو أعاد استخدامه من دون عرض نموذج الإعداد الذي يتيح للمستخدم عادةً اختياره أو إنشاؤه؟
كانت بيانات AppData القديمة مجرد فرضية من المجتمع
اقترح gelbuilding حذف /DATA/AppData/<app-name> أو إعادة تسميته حتى يتعامل المتجر مع التثبيت على أنه تثبيت جديد. وقال عضو آخر في المجتمع إنه استخدم الأسلوب نفسه.
لم يكن ذلك تشخيصًا من موظفي IceWhale، وأظهر الاختبار اللاحق الذي أجراه صاحب المنشور أنه غير كافٍ لمعالجة المشكلة الأوسع.
يغيّر تجاوز التطبيقات المثبتة للمرة الأولى للنموذجَ التشخيصَ
بمجرد أن بدأت التطبيقات الجديدة التي لا تملك بيانات AppData محلية سابقة بتجاوز الإعداد أيضًا، أصبح حذف المجلدات القديمة بشكل متكرر حلقة استكشاف أخطاء غير مناسبة. فقد ذكر المستخدم صراحةً أن إعادة التشغيل، ثم حذف المجلد، ثم إعادة التثبيت أدت إلى النتيجة نفسها.
كان نجاح التثبيت عبر YAML دليلًا مهمًا
ذكر المستخدم أنه لا يزال بإمكانه تثبيت التطبيقات من YAML. وهذا يشير إلى أن Docker نفسه لم يكن معطلًا بالكامل، ويضيّق نطاق المشكلة التاريخية نحو سير عمل تعريف التطبيق أو إعداداته أو عرضه داخل المتجر.
أعاد ZimaOS 1.7 بناء بنية متجر التطبيقات
قدّم ZimaOS 1.7.0 متجر التطبيقات 2.0 بواجهة جديدة للاستكشاف والإدارة، مع دعم أصلي لتحرير YAML وتحليله. ثم أضاف ZimaOS 1.7.1 مزيدًا من الإصلاحات المتعلقة بـ Docker وAppData وWebUI وYAML.
راجع الأساس الحالي لمتجر التطبيقات 2.0.
ترتيب الاستكشاف الحالي
- حدّث إلى أحدث إصدار مستقر من ZimaOS؛
- اختبر تطبيقًا بسيطًا من التطبيقات الرسمية لم يسبق تثبيته؛
- سجّل مسار الربط المفقود الدقيق على المضيف؛
- تحقق مما إذا كان المجلد موجودًا وأي وحدة تخزين ينتمي إليها؛
- تحقق مما إذا كان تثبيت YAML ينجح باستخدام المسار المقصود نفسه؛
- اجمع سجلات متجر التطبيقات/الحاوية إذا ظل نموذج الإعداد لا يعمل.
لا تحذف AppData عشوائيًا في التطبيقات التي تحتفظ بالبيانات
قد يحتوي مجلد AppData على قواعد بيانات وإعدادات ومفاتيح ومكتبات وبيانات المستخدم. وتُعد إعادة تسميته أكثر أمانًا من حذفه أثناء الاختبار، كما ينبغي نسخ البيانات المهمة احتياطيًا أولًا.
الأسئلة الشائعة حول نموذج الإعداد المفقود
هل أدى حذف AppData القديمة إلى حل المشكلة الأصلية نهائيًا؟
لا. فقد ذكر صاحب المنشور الأصلي أنه ساعد مرة واحدة، لكنه توقف عن العمل لاحقًا.
هل تأثرت التطبيقات المثبتة للمرة الأولى أيضًا؟
نعم. يذكر المنشور النهائي للمصدر أن التطبيقات الجديدة بدأت أيضًا بتجاوز نموذج الإعداد والتعطل.
هل ظل التثبيت عبر YAML يعمل؟
نعم. وكانت هذه إحدى أقوى الدلائل على أن الفشل التاريخي كان مرتبطًا بمسار متجر التطبيقات، وليس بتعطل Docker بالكامل.
