الخلاصة: نمط الفشل يطابق تفريغ النسخ عبر SMB بين مشاركتين على الخادم نفسه، وليس ملفًا مفقودًا
تبدأ عملية النسخ وتصل إلى ما يقارب 100%، ثم يعيد «مستكشف الملفات» المحاولة ويُبلغ بأن العنصر لم يعد موجودًا. في الوقت نفسه، ينجح نقل البيانات نفسها داخل «ملفات ZimaOS». يشير هذا الجمع إلى مسار النقل عبر SMB بين مشاركتين على الخادم نفسه، وليس إلى اختفاء الملف المصدر.
لماذا يتعامل Windows مع عمليات النسخ عبر SMB على الخادم نفسه بشكل مختلف؟
يمكن لـ Windows طلب إجراء النسخ من جانب الخادم عندما يكون المصدر والوجهة على خادم SMB نفسه. توثّق Microsoft هذه الآلية باسم FSCTL_SRV_COPYCHUNK. وإذا لم تتم معالجة هذا المسار بشكل صحيح، فقد يفشل «مستكشف الملفات» رغم نجاح عمليات القراءة والكتابة العادية لكل مشاركة.
استخدم مسار نقل لا يعتمد على تحسين النسخ بين مشاركتي الخادم نفسه في «مستكشف الملفات»
ثلاثة خيارات عملية:
- انقل الملفات أو انسخها في تطبيق «ملفات ZimaOS».
- انسخ المشاركة A إلى الكمبيوتر، ثم انسخها من الكمبيوتر إلى المشاركة B.
- استخدم
robocopyوتحقق من الوجهة.
توثّق Microsoft سلوك إعادة المحاولة والنسخ في مرجع robocopy.
لا تفترض مباشرةً أن المشكلة في الأذونات
إذا كان بإمكانك إنشاء الملفات وتحريرها وحذفها بشكل مستقل في كلتا المشاركتين، فمن المرجح ألا تكون بيانات الاعتماد الأساسية هي نقطة الفشل الأولى. يُعد مستند مساعدة SMB الحالي في ZimaOS المرجع المناسب عندما تكون إحدى المشاركتين للقراءة فقط أو تكون بيانات الاعتماد غير صحيحة.
ما يمكننا وما لا يمكننا تأكيده
تتطابق حالة المجتمع بقوة مع مشكلة توافق في النسخ من جانب الخادم، لكن الدليل العام الحالي لـ ZimaOS لا يوثّق سلوك COPYCHUNK بين المشاركات باعتباره ضمانًا مدعومًا. تعامل مع هذا النمط كاختصار تشخيصي، لا كتوصيف دائم للمنصة.
لإعداد المشاركة العادي، راجع دليل NAS 101 لمشاركة الملفات ومثال SMB الموثّق في ZimaOS.
