الروابط الصلبة في NTFS: لماذا يتغير ملفان معًا؟

ما الذي يعنيه وجود اسمين لملف واحد؟

الرابط الصلب تمثيل للملف يسمح بوصول أكثر من مسار إلى الملف نفسه. وفي نظام الملفات NTFS تخص هذه الروابط الملفات، لا المجلدات، وتبقى ضمن وحدة التخزين نفسها؛ فلا تنشئ بهذه الطريقة رابطًا من ملف على وحدة إلى ملف على وحدة أخرى. هذه حدود مهمة قبل تفسير أي نتيجة. [1]

لنبدأ بسؤال محدد: عندما تفتح اسمين وتقرأ الجملة نفسها، هل أمامك محتوى واحد أم نسختان متشابهتان؟ لا تجيب الجملة وحدها عن ذلك. اخترنا للاختبار ثلاثة أسماء قصيرة يسهل تمييزها: الأول هو a.txt، والثاني هو b.txt، والثالث هو copy.txt. كتبنا نصًا واحدًا في البداية كي تكون المقارنة واضحة، ثم راقبنا ما يحدث بعد تغيير مقصود، مع تسجيل هوية كل ملف في كل مرحلة.

في نتيجة البداية كان الاسمان الأول والثاني يحملان الهوية نفسها، بينما حمل اسم النسخة هوية أخرى، رغم أن النصوص الثلاثة متطابقة. هذه الملاحظة تفسر لماذا لا تكفي قراءة المحتوى لتحديد العلاقة بين الأسماء. لو اكتفينا بفتح الملفات الثلاثة لخرجنا بوصف صحيح لكنه ناقص: النص متساوٍ. أما السؤال الذي نبحثه فهو ما إذا كان تعديل أحد المسارات سيظهر عند القراءة من المسار الآخر.

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

إعداد تجربة صغيرة يمكن تتبعها

أجرينا الاختبار على ملفات نصية جديدة داخل مجلد مخصص له، بعد التحقق من أن نظام ملفات القرص هو إن تي إف إس. كانت البيئة ويندوز مع باورشيل بالإصدار 7.6.5. لم نستخدم مستند عمل أو ملفًا من مجلد البرامج. اخترنا عبارات قصيرة متتابعة حتى يمكن قراءة الفرق فورًا، واحتفظنا بسجل النتائج بدل الاعتماد على الذاكرة أو على ترتيب الملفات في نافذة المستكشف.

يتيح الأمر New-Item اختيار النوع HardLink في نظام الملفات، ويقبل Target لتحديد الملف المقصود. في السطور الآتية أنشأنا الاسم الثاني كرابط إلى الأول، ثم أنشأنا نسخة عادية للمقارنة. تنفذ هذه السطور داخل مجلد اختبار جديد وفارغ تختاره، وأسماؤها تخص الاختبار وحده. [3]

[IO.File]::WriteAllText("$pwd\a.txt", 'stage-one')
New-Item -ItemType HardLink -Path .\b.txt -Target .\a.txt
Copy-Item -LiteralPath .\a.txt -Destination .\copy.txt

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

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

ماذا حدث عند تعديل المحتوى عبر الاسم الثاني؟

كتبنا العلامة الثانية عبر المسار «ب» باستخدام عملية كتابة مباشرة إلى الملف. بعدها قرأنا «أ» و«ب» والنسخة من جديد. ظهرت المرحلة الثانية عند الاسمين الأول والثاني، وبقيت المرحلة الأولى عند النسخة. لم ننفذ أمرًا لنسخ المحتوى من «ب» إلى «أ»، ولم نستدع برنامج مزامنة بينهما؛ كانت العملية المقصودة في الاختبار كتابة واحدة، ثم ثلاث قراءات منفصلة لتسجيل النتيجة.

[IO.File]::WriteAllText("$pwd\b.txt", 'stage-two')

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

راقبنا هوية الملف أيضًا فبقيت مشتركة بين «أ» و«ب» بعد الكتابة، وظلت هوية النسخة مختلفة. الجمع بين المحتوى والهوية جعل تفسير التجربة أوضح من مقارنة علامة التعديل وحدها. فلدينا الآن ثلاثة أسئلة منفصلة: ماذا قرأنا؟ ومن أي مسار قرأناه؟ وما هو الملف الذي يمثله ذلك المسار؟ فصل هذه الأسئلة يمنع الخلط بين تطابق النص في لحظة معينة واستمرار ارتباط الاسمين عند حدوث تغيير.

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

كيف نفهم حذف اسم من قائمة الروابط؟

يعرض الأمر fsutil hardlink list الروابط الصلبة للملف المحدد. وتوضح وثائق مايكروسوفت أن حذف اسم واحد يختلف عن حذف جميع الروابط إلى الملف؛ فلا يحذف الملف من نظام الملفات إلا بعد إزالة جميع روابطه. استخدمنا عرض القائمة لمتابعة تجربة الاسم الثالث، دون اختبار حذف آخر رابط. [2]

fsutil hardlink list .\a.txt

أضفنا اسمًا ثالثًا جديدًا هو third.txt إلى الملف الذي يمثله «أ». قبل الحذف احتوت القائمة على ثلاثة مسارات، واحتفظنا بهذه القائمة في السجل. ثم حذفنا الاسم الثالث الذي أضفناه للتو، وقرأنا الاسمين الباقيين. ظل النص فيهما هو المرحلة الثانية، وعادت القائمة إلى اسمين. لم نلمس اسم النسخة في هذه الخطوة، ولم نستنتج من بقاء المحتوى إمكان حذف بقية الأسماء بلا أثر.

هذا التفصيل يغير طريقة صياغة السؤال عند مراجعة مجلد: هل تريد إزالة اسم زائد، أم الاحتفاظ بمحتوى سابق، أم التأكد من استقلال ملف؟ لكل غرض اختبار مختلف. في مثالنا نجحت إزالة الاسم الثالث في تقليل الأسماء الظاهرة، لكنها لم تعد النص إلى المرحلة الأولى. ولذلك لا تصلح نتيجة الحذف دليلًا على وجود نسخة سابقة؛ فقد بقي الاسمان الآخران يقرآن البيانات التي عدلناها بالفعل.

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

لماذا يختلف الاستبدال عن الكتابة داخل الملف؟

في المرحلة التالية أنشأنا ملفًا جديدًا بعلامة ثالثة، ثم استخدمنا عملية الاستبدال File.Replace لوضعه مكان «ب»، مع اسم محفوظ للمحتوى السابق هو before-replacement.txt. بعد العملية قرأنا «أ» فوجدنا المرحلة الثانية، وقرأنا «ب» فوجدنا الثالثة. كما اختلفت هويتهما. هذه نتيجة تنفيذ محدد سجلناه فعليًا؛ ليست توقعًا مأخوذًا من شكل زر الحفظ في محرر نصوص.

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

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

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

كيف تستخدم النتائج لتشخيص حالتك؟

ابدأ من السؤال الذي تريد الإجابة عنه، ثم اختر الملاحظة المناسبة. إذا كان السؤال عن تغير نصين معًا، فدوّن المسارين والنص قبل التعديل وبعده. وإذا كان عن ارتباط الاسمين، فاقرأ قائمة الروابط وسجل أسماءها. أما إن كان هدفك الاحتفاظ بمراجعة سابقة، فاختبر هل بقي النص السابق قابلًا للقراءة بعد العملية التي تستخدمها فعلًا. في تجربتنا كانت هذه أسئلة مختلفة، وجمْعها في حكم واحد كان سيخفي نتائج مهمة.

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

وإذا لم تظهر في جهازك النتيجة المتوقعة، فلا تبدأ بتغيير إعدادات النظام عشوائيًا. قارن أولًا الملفات التي فحصتها بأسماء الاختبار، وتحقق من نجاح الأمر بدل تفسير رسالة خطأ على أنها قائمة فارغة. ثم حدد العملية التي جرت فعلًا: هل كتبت داخل الملف أم استبدلت المسار؟ احتفظ بالنتيجة غير المتوقعة لتراجعها. لم تشمل تجربتنا خدمة سحابية أو مشاركة شبكة أو برنامج نسخ احتياطي، لذلك لا تحسم سلوك هذه البيئات.

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