مطبّات محرّك الشبكة ومسار UNC ── التعامل العملي مع خادم الملفّات (المجلّد المشترك) في تطبيقات الأعمال

«كان يعمل على جهاز التطوير، لكن عند العميل يقولون إنّ Z:\ غير موجود» «ما إن وُضع في جدولة المهام حتّى فشل الإخراج إلى المجلّد المشترك» «بعد تحويله إلى خدمة Windows اختفى خادم الملفّات» ── في استشارات تطبيقات الأعمال، أعطال خادم الملفّات (المجلّد المشترك) من أكثر الأنماط تكراراً. استيراد بيانات الطلبات، إخراج التقارير وCSV، مراقبة الملفّات التي يُصدرها جهاز. في أنظمة الأعمال المحلّية (on-premises) ما يزال المجلّد المشترك ركيزة تكامل قائمة.

والمزعج أنّ كثيراً من هذه الأعطال ليس «علّة في الشيفرة»، بل ينبع من آليّات Windows: علاقة حرف القرص بجلسة تسجيل الدخول، حساب تشغيل الخدمة والمصادقة، وإدارة اتّصالات SMB. تتبّع الأمر بالمصحّح لا يوصل إلى السبب، ويذوب الوقت عند «لا يتكرّر على جهازي».

يستهدف المقال مطوّري تطبيقات الأعمال (WinForms / WPF / خدمات Windows) الذين ينفّذون الإخراج والاستيراد والمراقبة نحو المجلّد المشترك. نرتّب مطبّات محرّك الشبكة ومسار UNC من الآليّة، ثمّ نجمع القواعد العمليّة في جدول قرار.

البيئة المفترضة

حديث المصادقة يتغيّر إذا تغيّرت المقدّمات، لذا نثبّت البيئة المفترضة أوّلاً.

أهمّ تفرّع في هذا المقال هو: نطاق أم مجموعة عمل. خيارات حساب التشغيل في الفصل 3 (حساب الحاسوب وgMSA) لا تقوم إلّا بوجود نطاق. بلا نطاق تميل الإجابة إلى الفصل 4: تمرير بيانات الاعتماد صراحة. تحقّق أوّلاً ممّا لديكم ثمّ واصل القراءة.

الاختصارات المستخدمة في المقال

1. الخلاصة أوّلاً

• حرف القرص (مثل Z:) ليس مورداً على مستوى النظام، بل يخصّ جلسة تسجيل الدخول. تُخصَّص لكلّ جلسة مجموعة أحرف من A إلى Z، لذلك لا يرى عمليّة مستخدم آخر، ولا خدمة في جلسة أخرى، القرص الذي ربطه المستخدم.²
• مع UAC مفعّلاً للمسؤول تُنشأ جلستا تسجيل دخول مرتبطتان: واحدة بصلاحيّات عاديّة وأخرى للرفع، وربط القرص (الرابط الرمزي لـ DosDevices) مستقلّ لكلّ جلسة. من هنا يأتي «Z: لا تظهر إلّا من التطبيق المرفوع». يوجد تجنّب عبر قيمة السجلّ EnableLinkedConnections لمشاركة الربط بين الجلستين، لكن Microsoft تنصّ صراحة على أنّه إعداد غير مدعوم «قد يجعل النظام غير آمن».³⁴
• عندما تصل خدمة (أو عمليّة في سياق أمني مختلف) إلى مورد بعيد، التوجيه الرسمي هو مسار UNC (\\server\share\...). ربط حرف قرص من داخل الخدمة بـ net use أو دوال WNet غير موصى به، من زاوية تسرّب بيانات الاعتماد والتداخل بين الخدمات.²
• من يُمنح الصلاحيّة على جانب المشاركة يحدّده حساب تشغيل الخدمة. LocalSystem وNetworkService يُصادَقان على الشبكة بـ«بيانات اعتماد الحاسوب»، وLocalService يصبح بيانات اعتماد مجهولة فلا يصلح للوصول إلى المشاركة. خدمة بحساب مستخدم محلّي لا تصل إلى موارد الشبكة. الخيار العملي هو حساب نطاق، أو gMSA الذي يترك إدارة كلمة المرور لنظام التشغيل. غير أنّ gMSA يفترض بيئة نطاق ومفتاح جذر KDS (الفصل 3).⁵⁶⁷⁸¹⁹
• لا يمكن الاتّصال في الوقت نفسه بالخادم نفسه بأكثر من مجموعة بيانات اعتماد. يفشل الاتّصال الثاني بالخطأ 1219 (ERROR_SESSION_CREDENTIAL_CONFLICT)، وهذا سلوك مقصود (by design).¹⁰¹¹
• المجلّد المشترك «بطيء، ينقطع، وقد لا يكون موجوداً» حالة طبيعيّة. يقطع الخادم الاتّصال الخامل افتراضيّاً بعد 15 دقيقة (ويُعاد الاتّصال عند الوصول التالي). File.Exists يُرجع false بلا استثناء عند نقص الصلاحيّة أو الخطأ، فلا يفرّق بين «الملفّ غير موجود» و«الخادم لا يُبلَغ».¹²¹³
• يدعم FileSystemWatcher مراقبة محرّك الشبكة والحاسوب البعيد، لكن صمّم على افتراض فقدان الأحداث. قد تُفقَد الأحداث عند فيضان المخزن، ويُقيَّد سقف المخزن الداخلي بـ 64 كيلوبايت عبر الشبكة. ضمّ المسح الكامل (polling) قاعدة ثابتة.¹⁴

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 31، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. العلاقة بين حرف القرص ومسار UNC ── Z: ملك «جلسة تسجيل دخولك»

عندما تربط \\fileserver\share بـ Z: من مستكشف الملفّات، يبدو وكأنّ «قرص Z:» نبت على الآلة كلّها. هذا أوّل سوء فهم.

الوثائق الرسميّة صريحة. حرف القرص ليس عامّاً على مستوى النظام؛ تُخصَّص مجموعة من A إلى Z لكلّ جلسة تسجيل دخول. لا تُشارَك الأقراص المُعاد توجيهها (محرّك الشبكة) بين عمليّات بحسابات مستخدمين مختلفة، ولا تصل خدمة في جلسة أخرى إلى حرف قرص أُنشئ في جلسة أخرى.² يدير النظام ربط الأقراص استناداً إلى SID جلسة تسجيل الدخول الذي يميّزها.²

أي أنّ Z: ليست سوى «مجموعة رموز اختصار للمسار، مجموعة لكلّ جلسة»، أمّا الجوهر فدائماً مسار UNC. بالرسم يكون الأمر كالتالي.

flowchart TB
    subgraph SA["جلسة تسجيل الدخول A ── مستخدم سجّل دخولاً تفاعليّاً"]
      EXP["مستكشف الملفّات<br/>تطبيقات شُغِّلت من سطح المكتب"]
      ZA["مجموعة أحرف أقراص هذه الجلسة<br/>Z: مربوط بالمشاركة"]
      EXP --- ZA
    end
    subgraph SB["جلسة تسجيل الدخول B ── خدمة / جدولة المهام"]
      SVC["خدمة Windows<br/>دفعة مجدولة"]
      ZB["مجموعة أحرف أقراص هذه الجلسة<br/>Z: غير مخصَّص"]
      SVC --- ZB
    end
    UNC["جوهر المجلّد المشترك<br/>مسار UNC ── share على fileserver01"]
    ZA -->|"يُبلَغ عبر Z:"| UNC
    ZB -.->|"Z: غير موجود. مسار UNC يبلغه"| UNC

الشكل 1: لكلّ جلسة تسجيل دخول مجموعة أحرف أقراص، بينما مسار UNC الجوهري واحد.

المهم أنّ هذا الفصل ليس لأنّ «المستخدم مختلف». حتّى إن هيّأت الخدمة لتعمل بحساب المستخدم نفسه في الجلسة A، ينشئ النظام جلسة تسجيل دخول جديدة للخدمة، فلا يُورَث الربط الذي أُنشئ في الجلسة A.² استشارة «جعلت حساب تشغيل الخدمة حسابي نفسه وما زال Z: غير موجود» تأتي من الخلط هنا.

من هنا تُفسَّر الأعراض المتكرّرة في الميدان على التوالي.

يستحقّ موضوع UAC تفصيلاً أطول. عندما يسجّل مستخدم من مجموعة المسؤولين دخوله، ينشئ النظام جلستين مرتبطتين: واحدة برمز مميّز مقيَّد الصلاحيّات وأخرى برمز مسؤول كامل. جوهر ربط القرص كائن رابط رمزي (DosDevices) يقابل حرف القرص بمسار UNC، وهو خاصّ بجلسة تسجيل الدخول ولا يُشارَك بين الجلسات.³ نصوص تسجيل الدخول تعمل في جانب الصلاحيّات العاديّة، لذلك لا ترى العمليّة المرفوعة ذلك الربط.

إذا ضُبط EnableLinkedConnections (قيمة DWORD في HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System) على 1، يُكتَب الرابط الرمزي في الجلستين المرتبطتين ويختفي العرض. لكن الوثائق الرسميّة تنصّ على أنّ «هذا التجنّب قد يجعل النظام غير آمن. لا تدعم Microsoft هذا التجنّب. استخدمه على مسؤوليّتك».⁴ اقتراح زرع إعداد غير مدعوم في سجلّ بيئة العميل حلّ سيّئ لتطبيق أعمال. الطريق الصحيح كتابة جانب التطبيق بمسار UNC. ودليل استكشاف أخطاء Folder Redirection الرسمي يوصي أيضاً بـ«استخدام مسار UNC دائماً لا حرف القرص».⁴

في التنفيذ يكفي حفظ المسار في ملفّ الإعدادات بصيغة UNC.

// appsettings.json ── ドライブ文字ではなくUNCで持つ
{
  "FileTransfer": {
    "IncomingDir": "\\\\fileserver01\\edi\\incoming",
    "ProcessedDir": "\\\\fileserver01\\edi\\processed"
  }
}

إن أمكن للمستخدم اختيار مسار تحت Z: من حوار اختيار المجلّد، فطبّع المسار إلى UNC عند الحفظ حتّى لا ينكسر لاحقاً إذا تغيّر سياق التشغيل. لتحويل حرف القرص إلى UNC تتوفّر الدالّة WNetGetUniversalName.¹⁵

3. الوصول إلى مجلّد مشترك من خدمة Windows ── UNC إلزامي، ثمّ «باسم مَن» يتمّ الوصول

كما في الفصل السابق، لا تستخدم الخدمة القرص المربوط. تقول الوثائق الرسميّة إنّ الخدمة (والعمليّة في سياق أمني مختلف) ينبغي أن تصل إلى المورد البعيد باسم UNC، وتنهى صراحة عن ربط حرف قرص وقت التشغيل من داخل الخدمة بـ net use أو دوال WNet. الأسباب المذكورة: ظهور الربط لخدمات أخرى في السياق نفسه، احتمال تسرّب بيانات الاعتماد الممرَّرة إلى net use خارج حدود الخدمة، وتداخل خدمات عدّة تحاول الربط نفسه فتفشل بخطأ «متّصل مسبقاً».²

بعد اعتماد مسار UNC يأتي سؤال المصادقة. باسم مَن تصل الخدمة إلى خادم الملفّات؟ يحدّده حساب التشغيل، وهو أيضاً من ينبغي منحه الصلاحيّة على جانب المشاركة.

أن يخرج LocalSystem وNetworkService إلى الشبكة «كحاسوب» مواصفة موثَّقة رسميّاً.⁵⁶ وثائق BITS تذكر النتيجة العمليّة: «إذا قيّدت ACL الملفّ المصدري الوصول بحساب مستخدم، تُرفَض الخدمة (التي تُصادَق ببيانات اعتماد الحاسوب)» و«لا ينبغي لحساب النظام استخدام قرص مربوط».¹⁷

من هذا تُستخرج ثلاثة توجيهات عمليّة.

• التفريق الأوّل لـ«رُفض الوصول بعد جعله خدمة» هو التحقّق من حساب التشغيل. على سطح المكتب كانت الصلاحيّة «صلاحيتك»، وفي الخدمة يُفحَص الوصول بهويّة الجدول أعلاه. راجع أذونات المشاركة وACL في NTFS لتلك الهويّة معاً.
• للتشغيل الطويل في بيئة نطاق، اجعل حساب التشغيل حساب نطاق أو gMSA. يحدّث نظام التشغيل كلمة مرور gMSA العشوائيّة بطول 240 بايت كل 30 يوماً، فيُلغى بنيويّاً حادث من نوع «انتهت كلمة مرور حساب الخدمة وتوقّف كلّ شيء صباح الاثنين».¹⁶
• في مجموعة عمل (بلا نطاق) لا تقوم المصادقة ببيانات اعتماد الحاسوب، فيظهر دور بيانات الاعتماد الصريحة في الفصل التالي.

ولـ gMSA مقدّمات. وصفناه بـ«الخيار الأرجح»، لكنّه ليس جاهزاً في اليوم الذي تخطر فيه الفكرة. gMSA توسيع لـ sMSA (standalone Managed Service Account) الموجَّه لخادم واحد كي يعمل عبر خوادم عدّة، وهو حساب نطاق يوفّر إدارة تلقائيّة لكلمة المرور وتبسيط إدارة SPN.¹ تحقّق ممّا يلي قبل الاعتماد.

البنود تتطلّب تنسيقاً مع مسؤول النطاق، لذا إن اقترحت تصميماً يفترض gMSA، اسأل مسؤول البنية أوّلاً عن هذه النقاط الخمس. إن تعذّر التأكيد أو لم تدخل ساعات الانتظار العشر في الجدول الزمني، ابنِ أوّلاً بحساب نطاق عادي، وهيّئ التبديل إلى gMSA ليكون مجرّد تغيير حساب التشغيل.

بناء الخدمة نفسها (ضبط حساب التشغيل، خيارات الاستعادة، الإيقاف الآمن) مشروح في «كيفيّة بناء خدمات Windows وتشغيلها»، وآليّة الجلسات وتسجيل الدخول في «كيف نفهم عزل الجلسات في Windows».

4. التعامل مع بيانات الاعتماد ── net use، مدير بيانات الاعتماد، والخطأ 1219

إن تعذّر منح حساب التشغيل نفسه صلاحيّة على جانب المشاركة (مجموعة عمل، NAS بحسابات خاصّة، إلخ) تُمرَّر بيانات الاعتماد صراحة للاتّصال. الوسائل ثلاث أساساً.

• net use \\server\share /user:... ── يُنشئ اتّصالاً في جلسة تسجيل الدخول تلك. مفيد للتحقّق التفاعلي، لكن تشغيله من داخل الخدمة غير موصى به كما في الفصل السابق.²
• مدير بيانات الاعتماد (cmdkey) ── بحفظ cmdkey /add:server /user:svc-file /pass:... تُستخدم بيانات الاعتماد المحفوظة تلقائيّاً عند المصادقة اللاحقة على ذلك الخادم.¹⁸¹⁹ الحفظ بوحدة ملفّ تعريف المستخدم، لذا إن استُخدم من خدمة يلزم التسجيل في سياق حساب تشغيل الخدمة. هذا مطبّ شائع.
• الاتّصال من البرنامج (WNetAddConnection2) ── يمكن إنشاء اتّصال بمورد شبكة مع تحديد بيانات اعتماد العميل. الوثائق الرسميّة تعدّه إحدى استراتيجيّات وصول عمليّة خادم إلى موارد الشبكة.²⁰ باتّصال بلا جهاز (deviceless) يبقى الوصول بمسار UNC.

وأشهر مطبّ في هذا المجال هو الخطأ 1219.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. (ERROR_SESSION_CREDENTIAL_CONFLICT, 1219)¹¹

لا يمكن من الجلسة نفسها فتح أكثر من اتّصال بالخادم نفسه بأسماء مستخدمين مختلفة. إن حاولت «مشاركة المبيعات بحسابي، ومشاركة التكامل بحساب مخصّص» على خادم الملفّات نفسه، يفشل الثاني بـ 1219. الوثائق الرسميّة تصرّح أنّ هذا «by design (مواصفة)»، والتجنّبات المذكورة هي «الاتّصال بعنوان IP» أو «إنشاء اسم مستعار DNS آخر» ── أي إظهاره كخادم آخر.¹⁰

في الممارسة الخيار الأوّل تجنّب استخدام أكثر من مجموعة بيانات اعتماد لخادم واحد أصلاً. اجمع حساب التكامل في حساب واحد، وامنحه الصلاحيّة على كلّ المشاركات اللازمة. إن وُجد سبب يمنع ذلك فقط، فافصل المسار باسم مستعار (alias).

غير أنّ الاسم المستعار ليس «سطراً CNAME في DNS وينتهي الأمر». في بيئة Kerberos يطلب عميل SMB المصادقة بـ SPN يقابل اسم الوجهة، لذا إن لم يُسجَّل SPN للاسم المستعار قد يفشل الوصول عبر CNAME نفسه. دليل الاستكشاف الرسمي يعدّ غياب SPN أحد الأسباب، ويرشد إلى تعريف الاسم المستعار كاسم حاسوب إضافي بـ netdom computername <اسم الخادم> /add:<الاسم المستعار> لا بـ CNAME في DNS.²¹ قبل إدخال الاتّصال عبر الاسم المستعار في التصميم كعلاج لـ 1219، اختبره حتماً في البيئة المستهدفة.

أمّا المتطلّب المتقدّم «تريد الخدمة الوصول إلى خادم الملفّات بصلاحيّات مستخدم العميل المتّصل» فليس إعادة استخدام بيانات اعتماد، بل مجال الانتحال (impersonation). الوثائق الرسميّة توصي بالانتحال بدل احتفاظ الخدمة ببيانات الاعتماد.² الكتابة الصحيحة للانتحال، وما يلزم من اعتبار إضافي على المورد البعيد، في «التعامل الصحيح مع رموز الانتحال في Windows».

تشخيص بيئتك ── الأوامر التي تُنفَّذ أوّلاً

ما سبق لا يصبح ممارسة إلّا إذا أمكنت قراءة الحالة في البيئة التي يظهر فيها العرض. نقطة التفريق هي باسم مَن تعمل تلك العمليّة، وأيّ اتّصالات تملك. نفّذ الثلاثة التالية في سياق التنفيذ نفسه الذي يظهر فيه العرض.

المهم التنفيذ في السياق نفسه. net use من سطح مكتبك لا يحدّث عن اتّصالات الخدمة. للتحقّق بحساب تشغيل الخدمة، سجّل مؤقّتاً مهمّة في جدولة المهام بالحساب نفسه وإعدادات الامتياز نفسها، مثل cmd /c "whoami > C:\temp\who.txt & net use >> C:\temp\who.txt"، ثمّ اقرأ ملفّ الخرج.

إعادة إنتاج الخطأ 1219 على جهازك

1219 يُفهَم أسرع إذا أخرجته بنفسك مرّة بدل قراءة الشرح. على جهاز منضمّ إلى نطاق، اتّصل بمشاركتين على خادم الملفّات نفسه ببيانات اعتماد مختلفة.

:: 1) 自分のアカウントで1つ目の共有に接続する(パスワードは * でプロンプト入力)
net use \\fileserver01\share1 * /user:CONTOSO\tanaka

:: 2) 同じサーバーの別の共有に、別のアカウントで接続しようとする
net use \\fileserver01\share2 * /user:CONTOSO\svc-file
::    → ここで上に引用したエラー 1219 が返り、接続できない

:: 後片付け:このセッションのネットワーク接続をすべて切る
net use * /delete

النقطة أنّ الاختلاف في المشاركة لا يمنع التصادم إن كان الخادم واحداً. لا يهم أن تكون الأولى share1 والثانية share2. القيد بوحدة الخادم. بالمقابل، إن قطعت الأولى بـ net use \\fileserver01\share1 /delete ثمّ أنشأت الثانية نجحت ── أي قد تمرّ حسب الترتيب، فتظهر في الإنتاج أوّل مرّة دون أن تتكرّر أثناء التطوير. إن استخدمت عنوان IP أو اسماً مستعاراً كتجنّب، لا تنسَ مقدّمة SPN المذكورة للتوّ.¹⁰²¹

5. التصميم على افتراض «بطيء، ينقطع، وقد لا يكون موجوداً»

الشيفرة المكتوبة بإحساس القرص المحلّي تصطدم حتماً بالمجلّد المشترك. ثلاث وقائع ينبغي افتراضها.

أوّلاً، انقطاع الاتّصال حالة طبيعيّة. يُقطع الاتّصال الخامل بعد مهلة افتراضيّة 15 دقيقة لتوفير موارد الخادم. ظاهرة علامة × الحمراء على محرّك الشبكة في المستكشف هي هذا، ويُعاد الاتّصال سريعاً عند الوصول التالي.¹² أي أنّ «تطبيق أعمال نادر الوصول ينتظر لحظة في كلّ وصول» و«أداة المراقبة تصيح انقطع! دون ضرر فعلي» سلوك مطابق للمواصفة. لا تراقب وجود الاتّصال، بل احكم بنجاح الإدخال/الإخراج الفعلي.

يمكن تغيير هذه المهلة. انتبه أنّ هناك مؤقّتين: على الخادم وعلى العميل، والأقصر يفوز.¹²

السطر الأخير سهل الإغفال. افتراضي العميل 10 دقائق، أقصر من افتراضي الخادم 15 دقيقة، لذا إطالة جانب الخادم وحده لا تغيّر سلوك القطع. تُقطع الجلسة بـالأقصر بين autodisconnect وKeepConn.¹²

ومع ذلك تغيير هذه القيم ليس الخيار الأوّل. القطع سلوك مطابق للمواصفة، ويُعاد الاتّصال عند الوصول التالي فلا ضرر عادة. غيّر القيم فقط إن كان لديك تطبيق قديم يسقط عند كلّ قطع ولا يمكن لمسه، وبعد الاتّفاق مع مسؤول الخادم لأنّ الإعداد يؤثّر على أنظمة أخرى. جانب التطبيق يميل إلى «إعادة المحاولة على افتراض الانقطاع».

ثانياً، شكل الخطأ غير ودّي. File.Exists يُرجع false بلا استثناء إن كان المسار غير صالح، أو نقصت الصلاحيّة، أو حدث عطل في القرص.¹³ محلّيّاً يكفي تقريباً «false يعني غير موجود»، أمّا مع المشاركة فـ«الملفّ غير موجود» و«الخادم لا يُبلَغ / لا صلاحيّة» تُطوى كلّها في false، فـالشيفرة التي تتفرّع بـ Exists لاتّخاذ حكم عمل تنتهي نجاحاً عند عطل الشبكة وكأنّه «لا هدف». مع المشاركة أسهل تشخيصاً أن تفتح مباشرة وتفرّق بالاستثناء، دون فحص وجود مسبّق.

ثالثاً، الطرف المقابل قد لا يكون موجوداً بعد. بعد إقلاع الآلة قد تسبق الخدمة تجهيز الشبكة، وقد يكون خادم الملفّات يعيد التشغيل. الاتّصال الدائم (persistent connection) يُستعاد عند تسجيل دخول المستخدم²³، لذا في عالم الخدمة الذي لا يمرّ بتسجيل دخول لا ضمان لـ«المشاركة ظاهرة بعد البدء». لا تفحص الاتّصال مرّة عند البدء ثمّ تنهِ عند الفشل؛ الانتظار مع إعادة المحاولة هو السلوك الصحيح.

إذا نُسجت هذه الثلاث، يصبح هيكل جانب الكتابة كالتالي.

// أعد محاولة أخطاء الشبكة العابرة، وأفشل فوراً أخطاء العمل
private static async Task WriteToShareAsync(string finalPath, byte[] content, CancellationToken ct)
{
    var dir = Path.GetDirectoryName(finalPath)!;
    var tempPath = Path.Combine(dir, $"~{Guid.NewGuid():N}.tmp");

    try
    {
        for (var attempt = 1; ; attempt++)
        {
            try
            {
                await File.WriteAllBytesAsync(tempPath, content, ct);
                File.Move(tempPath, finalPath); // rename داخل نفس المجلد ينشر «اكتمال»
                return;
            }
            catch (IOException ex) when (attempt < 5 && IsRetryable(ex))
            {
                // أعد فقط أعطال الشبكة العابرة بتراجع أسي (بسقف)
                _logger.LogWarning(ex, "فشل الكتابة إلى المشاركة (المرّة {Attempt}). ستُعاد المحاولة", attempt);
                await Task.Delay(TimeSpan.FromSeconds(Math.Pow(2, attempt)), ct);
            }
        }
    }
    catch
    {
        // عند التخلّي ونشر الاستثناء، نظِّف الملف المؤقت بجهد أفضل
        try { File.Delete(tempPath); } catch { /* ابتلع فشل التنظيف */ }
        throw;
    }
}

// IOException يأتي بنفس النوع لـ «انقطاع الشبكة» و«ملف بنفس الاسم في الوجهة» و«القرص ممتلئ».
// اختر بـ 16 بت الأدنى من HResult (رمز خطأ Win32) الأعطال العابرة التي تستحق إعادة المحاولة فقط
private static bool IsRetryable(IOException ex)
{
    var win32 = ex.HResult & 0xFFFF;
    return win32 is 53   // ERROR_BAD_NETPATH: مسار الشبكة غير موجود
              or 59   // ERROR_UNEXP_NET_ERR: خطأ شبكة غير متوقَّع
              or 64   // ERROR_NETNAME_DELETED: اسم الشبكة لم يعد متاحاً
              or 121; // ERROR_SEM_TIMEOUT: مهلة (مهلة semaphore)
}

مهم أيضاً ألّا تكتب «إن كان IOException فأعد المحاولة» بشكل فضفاض. وجود ملفّ بالاسم نفسه في الوجهة، وطول المسار الزائد، وامتلاء القرص، كلّها إخفاقات لا يتغيّر نتيجتها بالتكرار وتصل بالنوع نفسه IOException، فالحكم بنوع الاستثناء وحده يعيد المحاولة خمس مرّات على خطأ دائم ويضيّع الوقت في التراجع الأسي. كما في المثال، صفِّ بأكواد خطأ Win32 (53 / 59 / 64 / 121 وغيرها من انقطاع المشاركة والمهلة²⁴) «الإخفاق الذي يستحقّ إعادة المحاولة» فقط. العملي أن تضيف ما رصدته في سجلات البيئة الفعليّة.

النقطة ليست إضافة إعادة المحاولة بحدّ ذاتها، بل ربطها ببروتوكول تسليم آمن عند التكرار (temp -> rename، idempotency). إن انقطع الاتّصال أثناء الكتابة بقي ملفّ ناقص. إن كان الاسم النهائي لا يظهر إلّا بـ«rename بعد الإغلاق»، منعت جهة الاستقبال من قراءة ملفّ نيء. ولاحظ أنّ انهيار العمليّة أو انقطاع التيّار لا يشغّل التنظيف داخل الشيفرة، لذا جهّز للمجلّد أيضاً كنساً دوريّاً يحذف ~*.tmp التي لم تُحدَّث منذ مدّة، حتّى لا يُسدّ بالمخلّفات. الصورة الكاملة لتصميم التسليم في «أساسيّات التحكّم الحصري في تكامل الملفّات».

وثمّة انتباه خاصّ بطرف الشبكة. نتيجة «فشل» لا تضمن أنّ الفشل وقع فعلاً. إن اكتمل rename على الخادم ثمّ انقطع الاتّصال، قد يرجع للعميل استثناء بينما الملفّ بالاسم النهائي منشور أصلاً. إعادة المحاولة بلا تفكير عندئذ إمّا تعلق بخطأ «يوجد ملفّ بالاسم نفسه في الوجهة»، أو تنشر البيانات مرّتين إن كانت جهة الاستقبال قد التقطت الأولى. العلاج أن تطابق حالة الوجهة قبل إعادة محاولة مرحلة rename. إن تضمّن الاسم النهائي معرّف معالجة (رقم القسيمة أو GUID التشغيل)، أمكن الحكم «ملفّ final بالمعرّف نفسه موجود أصلاً = rename السابق نجح في الحقيقة» والخروج بعدّه نجاحاً، وترفض جهة الاستقبال التقاطاً مزدوجاً بتكرار المعرّف.

6. التحكّم الحصري عبر SMB وموثوقيّة FileSystemWatcher

6.1. الإفراط في الثقة بالقفل ممنوع

المجلّد المشترك يُلمَس من عملاء كثر في الوقت نفسه. الفتح بـ FileShare.None يحقّق حصراً أثناء الفتح عبر SMB أيضاً، لكن التصميم الذي يركن إلى «ما دام القفل أُخذ فهو آمن» ينهار عند فقدان المقبض بالانقطاع، أو عند اختلاط طرف لا يأخذ قفلاً (نسخ يدوي، نظام آخر). موضع الحصر ليس قفل نظام التشغيل، بل جانب بروتوكول التسليم: temp -> rename، وclaim ذرّي (من يفوز بـ rename من incoming إلى processing يعالج وحده)، وidempotency. التفاصيل في مقال التحكّم الحصري أعلاه.

6.2. واقع استخدام FileSystemWatcher على مشاركة بعيدة

تصرّح الوثائق رسميّاً أنّ FileSystemWatcher يدعم مراقبة الملفّات لا محلّيّاً فقط بل على محرّك شبكة وحاسوب بعيد.¹⁴ الاستخدام نفسه مشروع. غير أنّ مقدّمتي الموثوقيّة اثنتان.

• الإشعارات تمرّ عبر مخزن مؤقّت، وتُفقَد عند الفيضان. إن تركّزت التغييرات في وقت قصير فُقدت الأحداث الزائدة عن حجم المخزن.¹⁴
• عند المراقبة عبر الشبكة يُقيَّد سقف InternalBufferSize بـ 64 كيلوبايت. قيد «لا يمكن تضخيمه» أوضح من المحلّي.¹⁴

وفوق ذلك، عندما يعيد الخادم خلف المشاركة التشغيل أو ينقطع الاتّصال، كثيراً ما تموت المراقبة بصمت دون إشعار؛ رأينا هذا مراراً في تحقيق الأعطال. الخلاصة العمليّة: FileSystemWatcher على مشاركة بعيدة «تلميح للإسراع في الانتباه»، ومصدر الحقيقة هو المسح الكامل (polling) عند البدء وعند الخطأ وبشكل دوري. أنماط التصميم التي تشمل تكرار الأحداث واختلال الترتيب مفصّلة في «دليل FileSystemWatcher العملي».

7. القواعد الثابتة في الممارسة (جدول القرار)

نجمع ما سبق في جدول قرار حسب النقاط التي يُحتار فيها عند التصميم.

نضيف توضيحاً للسطر الأخير. تكامل المجلّد المشترك سهل، لكن كلّما زاد مصدر الوصول صعبت إدارة «من بأيّ صلاحيّة» و«من يتعارض مع من» أسيّاً. إذا تجاوز الحجم حدّاً، اجمع العمليّة التي تلمس خادم الملفّات في خدمة Windows واحدة، ودَع كلّ عميل يتحدّث معها بـ HTTP أو gRPC. تخفيض المجلّد المشترك من «واجهة بين الأنظمة» إلى «تفصيل تنفيذ داخلي لتلك الخدمة» هو الشكل الأسهل صيانة على المدى الطويل.

8. الخلاصة

• حرف القرص رمز يخصّ جلسة تسجيل الدخول. عدم ظهوره لمستخدم آخر أو عمليّة مرفوعة أو خدمة مواصفة، والطريق الصحيح كتابة التطبيق بمسار UNC. EnableLinkedConnections تجنّب غير مدعوم.
• الوصول من الخدمة إلى المشاركة يتطلّب UNC. باسم مَن تتمّ المصادقة يحدّده حساب التشغيل: LocalSystem / NetworkService ببيانات اعتماد الحاسوب، وLocalService مجهول. الممارسة منح صلاحيّة المشاركة لحساب نطاق أو gMSA.
• الاتّصال المتزامن بأكثر من مجموعة بيانات اعتماد للخادم نفسه يفشل بالخطأ 1219 (مواصفة). تجنّبه من مرحلة التصميم بتجميع الحساب أو اسم مستعار DNS.
• المشاركة «بطيئة، تنقطع، وقد لا تكون موجودة» حالة طبيعيّة. قطع الخمول (افتراضيّاً 15 دقيقة) ليس عطلاً، وfalse من File.Exists لا يُميَّز عن عطل الشبكة. أدخل إعادة المحاولة مع temp -> rename وidempotency معاً.
• FileSystemWatcher يدعم المراقبة البعيدة، لكن بسبب فقدان الأحداث بفيضان المخزن وسقف 64 كيلوبايت، ضمّ المسح الكامل قاعدة ثابتة.
• عند التردّد ارجع إلى جدول الفصل 7. وإذا كبر الحجم، فكّر في جمع العمليّة التي تلمس المشاركة في خدمة وسيطة.

مقالات ذات صلة

• أساسيّات التحكّم الحصري في تكامل الملفّات - أفضل ممارسات قفل الملفّات وclaim الذرّي
• دليل FileSystemWatcher العملي - التعامل مع فقدان الأحداث والتكرار
• كيفيّة بناء خدمات Windows وتشغيلها ── من التمييز عن جدولة المهام إلى تحويل BackgroundService إلى خدمة
• كيف نفهم عزل الجلسات في Windows ── Session 0 وRDP والتشغيل المتزامن لعدّة مستخدمين
• التعامل الصحيح مع رموز الانتحال في Windows ── استعارة الصلاحيّات على مستوى الخيط وإعادتها بأمان

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم أنظمة تكامل الملفّات عبر المجلّد المشترك وتنفيذها، ودراسة تكوين الصلاحيّات والمصادقة عند التحويل إلى خدمة Windows، وتحقيق أعطال من نوع «لا تظهر المشاركة بعد جعلها خدمة» أو «تفشل في بيئة معيّنة فقط».

• تطوير تطبيقات Windows
• تحقيق الأعطال وتحليل الأسباب
• الاستشارة التقنيّة ومراجعة التصميم
• تواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

لماذا لا يمكن الوصول إلى محرّك الشبكة (Z:) من خدمة Windows؟

لأنّ حرف القرص ليس مورداً على مستوى النظام كلّه، بل يخصّ جلسة تسجيل الدخول. فـ Z: التي يربطها المستخدم من مستكشف الملفّات ليست سوى رمز داخل جلسة ذلك المستخدم، ولا تظهر لخدمة تعمل في جلسة تسجيل دخول أخرى. وحتّى إن عملت الخدمة بالحساب نفسه، ينشئ النظام جلسة تسجيل دخول جديدة للخدمة، فلا يُورَث الربط الذي أُنشئ من سطح المكتب. الوصول الصحيح من الخدمة هو مسار UNC بالصيغة \\server\share.

كيف تصل خدمة تعمل بحساب LocalSystem إلى مجلّد مشترك؟

يُصادَق LocalSystem على الشبكة ببيانات اعتماد الحاسوب. في بيئة نطاق يمكن الوصول بمنح حساب حاسوب تلك الآلة (DOMAIN\MACHINE$) صلاحيّات على جانب المشاركة (أذونات المشاركة وACL في NTFS). غير أنّ استبدال الآلة يعيد ضبط الصلاحيّات من الصفر، وهذا صعب التشغيل. في الممارسة يُفضَّل تشغيل الخدمة بحساب نطاق أو gMSA (حساب خدمة مُدار جماعيّاً) ومنح صلاحيّات المشاركة لذلك الحساب.

هل يجوز مراقبة ملفّات المجلّد المشترك بـ FileSystemWatcher؟

يمكن استخدامه، لكن لا تعتمد عليه وحده. يدعم FileSystemWatcher المراقبة على محرّك شبكة أو حاسوب بعيد، غير أنّ إشعارات التغيير تصل عبر مخزن مؤقّت، فإذا تركّزت الإشعارات فاض المخزن وفُقدت أحداث. وفوق ذلك يُقيَّد سقف المخزن بـ 64 كيلوبايت عند المراقبة عبر الشبكة. القاعدة الثابتة هي اعتبار الإشعار «محفّزاً لإعادة المسح»، مع مسح كامل (polling) عند البدء وعند الخطأ وبشكل دوري.

كيف يُصمَّم تكامل ملفّات يصمد أمام انقطاع الشبكة؟

صمِّم على أنّ «المشاركة بطيئة، وتنقطع، وقد لا تكون موجودة» حالة طبيعيّة. اكتب باسم ملفّ مؤقّت ثمّ أعد التسمية بعد الإغلاق لنشر الملفّ (temp -> rename)، وأحِط القراءة والكتابة بإعادة محاولة، وميّز خطأ الشبكة المؤقّت عن خطأ العمل. انتبه إلى أنّ File.Exists يُرجع false أيضاً عند تعذّر الوصول، فلا يفرّق بين «الملفّ غير موجود» و«الخادم لا يُبلَغ». الدرع الأخير معالجة idempotent لا تفسد إن أُعيد تنفيذها.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.