أعماق إدخال/إخراج Windows (الجزء 5) ── البنية الداخليّة لـ NTFS: فهم نظام الملفّات من MFT

عبر الأجزاء الأربعة حتّى الآن، تابعنا كيف يسير طلب إدخال/إخراج (الأجزاء 1–3) وكيف يستقبله مدير الذاكرة المؤقّتة (الجزء 4). في النهاية يصل الطلب إلى نظام الملفّات. هذه المرّة دور مثاله الرائد، NTFS.

تتغيّر الزاوية هنا. حتّى الآن كانت القصّة ديناميّة — تدفّق الطلب. هذه المرّة قصّة ساكنة عن كيف تُوضَع البيانات على القرص. الهويّة الحقيقيّة لـ «Zone.Identifier» غير المرئيّ المرفق بملفّ منزَّل. لماذا نسخ عشرة آلاف ملفّ صغير أبطأ بكثير من نسخ ملفّ واحد بالحجم الإجماليّ نفسه. إلى أيّ مدى يصدق أنّ «NTFS ذو سجلّ تدوين، لذا هو آمن» — كلّ ذلك يُفسَّر من هذه البنية.

هذا الجزء 5 من سلسلة «أعماق إدخال/إخراج Windows».

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

جدول 1: مصطلحات الأجزاء السابقة المفترضة في هذه الحلقة

أمر آخر: المرحلتان اللتان غطّاهما الجزء 1 — cleanup (حين يُغلق آخر مقبض) وclose (حين تختفي كلّ المراجع داخل النواة) — تُستخدمان أيضاً في شرح حذف الملفّ في الفصل 4.

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

• مركز NTFS هو MFT (جدول الملفّات الرئيسيّ). كلّ ملفّ يُدار كسجلّ في سجلّ MFT، وكلّ معلومات عن الملفّ إمّا «داخل إدخال MFT» أو «في المنطقة خارج MFT التي يشير إليها الإدخال» (الفصل 2).¹
• كيان الملفّ «مجموعة سمات». ملفّ صغير يتّسع فيه محتوى البيانات نفسه داخل سجلّ MFT (مقيم)، وملفّ كبير لا يحمل إلا مرجعاً إلى سلسلة عناقيد (غير مقيم). بطء معالجة عدد هائل من الملفّات الصغيرة يُفسَّر من هنا (الفصل 2).¹
• يمكن حمل عدّة بيانات (عدّة دفق بيانات). البيانات المعتادة «دفق بلا اسم»، ويمكن حمل دفق إضافيّ بـ file.txt:اسم. هويّة Zone.Identifier (Mark of the Web) (الفصل 3).²
• الاسم أيضاً سمة. ما يضع عدّة أسماء على السجلّ نفسه هو الرابط الصلب. واسم 8.3 المختصر أيضاً «اسم آخر» يجاور (الفصل 4).³⁴
• نقطة إعادة التحليل حيلة رسميّة لـ«إن فُتح فمكان آخر». الروابط الرمزيّة والوصلات وملفّات OneDrive عند الطلب كلّها تطبيقات لهذه البيانات ذات الوسم (الفصل 5).⁵⁶
• هناك سجلّا تدوين. $LogFile لـاستعادة اتّساق البيانات الوصفيّة (سجلّ سابق كي لا ينكسر)، وسجلّ USN لـتسجيل تاريخ التغيير (سجلّ ما تغيّر). الدوران مختلفان تماماً (الفصل 6).⁷⁸
• «الحجم» و«الحجم على القرص» شيئان مختلفان. الملفّات المتناثرة والضغط يولّدان الفارق. خلف «الملفّ المضغوط لا يصير لاتزامنيّاً» الذي رأيناه في الجزء 2 أيضاً هنا (الفصل 7).⁹¹⁰

خريطة المعرفة لهذه المقالة

مركز NTFS هو MFT (جدول الملفّات الرئيسيّ)، وتُدار كلّ الملفّات سجلاتٍ في دفتر MFT. البيانات الصغيرة مقيمة داخل السجلّ، والكبيرة تصير غير مقيمة ولا تحمل إلا مرجعاً إلى سلسلة العناقيد (مسار البيانات)؛ وهذا هو جوهر بطء معالجة الملفّات الصغيرة الكثيرة والتجزئة. تدفقات البيانات المتعدّدة والارتباط الثابت والاسم المختصر 8.3 تطبيقات للآليّة نفسها «مجموعة سمات»؛ ونقطة إعادة التوزيع هي الخطّاف الرسميّ على «الفتح» الذي يسند من الارتباط الرمزيّ حتّى ملفات OneDrive عند الطلب. ما يحميه $LogFile هو اتّساق البنية؛ أمّا ديمومة محتوى البيانات فتُبنى على حدة بأدوات التحكّم في الذاكرة المؤقّتة في الحلقة الرابعة.

flowchart LR
    accTitle: خريطة معرفة البنية الداخليّة لـ NTFS وMFT
    accDescr: مخطّط يبيّن علاقات NTFS وMFT وسجلّ الملفّ، والسمات المقيمة وغير المقيمة، ومسار البيانات، والتجزئة، وتعدّد تدفقات البيانات، وZone.Identifier، والارتباط الثابت، والاسم المختصر 8.3، ونقطة إعادة التوزيع (الارتباط الرمزيّ والوصلة وملفات OneDrive عند الطلب)، و$LogFile وسجلّ USN، والملفّ المتفرّق وضغط NTFS
    ntfs["NTFS"]
    mft["MFT (جدول الملفّات الرئيسيّ)"]
    mft_record["سجلّ ملفّ MFT"]
    mft_zone["منطقة MFT"]
    fragmentation["التجزئة (NTFS)"]
    resident_attribute["سمة مقيمة (resident)"]
    non_resident_attribute["سمة غير مقيمة (non-resident)"]
    data_run["مسار البيانات (data run)"]
    fsutil["fsutil"]
    alternate_data_stream["تدفق بيانات بديل (ADS)"]
    zone_identifier["Zone.Identifier (Mark of the Web)"]
    streams_tool["streams (Sysinternals)"]
    size_disk_usage_mismatch["تباعد الحجم المنطقيّ عن استخدام القرص"]
    hard_link["ارتباط ثابت"]
    eight_dot_three_name["الاسم المختصر 8.3"]
    reparse_point["نقطة إعادة التوزيع"]
    symbolic_link["ارتباط رمزيّ"]
    junction["وصلة (نقطة تركيب)"]
    onedrive_files_on_demand["ملفات OneDrive عند الطلب"]
    ntfs_logfile["$LogFile (سجلّ معاملات NTFS)"]
    volume_corruption["تلف وحدة التخزين"]
    cache_manager["مدير الذاكرة المؤقّتة"]
    usn_journal["سجلّ USN (سجلّ التغييرات)"]
    sparse_file["ملفّ متفرّق"]
    ntfs_compression["ضغط NTFS"]
    asynchronous_io["إدخال/إخراج لاتزامنيّ"]
    procmon["Process Monitor (procmon.exe)"]
    ntfs -->|"يستخدم"| mft
    mft -->|"يستخدم"| mft_record
    mft -->|"يشترط"| mft_zone
    mft_zone -.->|"يخفّف"| fragmentation
    mft_record -->|"يستخدم"| resident_attribute
    mft_record -->|"يستخدم"| non_resident_attribute
    resident_attribute -->|"لا يتوافق مع"| non_resident_attribute
    non_resident_attribute -->|"يستخدم"| data_run
    data_run -.->|"قد يسبّب"| fragmentation
    fragmentation -->|"يُتحقّق بـ"| fsutil
    ntfs -->|"يستخدم"| alternate_data_stream
    zone_identifier -->|"يُحفظ في"| alternate_data_stream
    zone_identifier -->|"يُتحقّق بـ"| streams_tool
    alternate_data_stream -->|"يُتحقّق بـ"| streams_tool
    alternate_data_stream -.->|"قد يسبّب"| size_disk_usage_mismatch
    ntfs -->|"يستخدم"| hard_link
    hard_link -->|"يشترط"| mft_record
    ntfs -.->|"يستخدم"| eight_dot_three_name
    eight_dot_three_name -->|"يُكوَّن بـ"| fsutil
    ntfs -->|"يستخدم"| reparse_point
    reparse_point -->|"يُتحقّق بـ"| fsutil
    symbolic_link -->|"ينفّذ"| reparse_point
    junction -->|"ينفّذ"| reparse_point
    onedrive_files_on_demand -->|"ينفّذ"| reparse_point
    ntfs -->|"يستخدم"| ntfs_logfile
    ntfs_logfile -->|"يخفّف"| volume_corruption
    ntfs -->|"يستخدم"| cache_manager
    ntfs -->|"يستخدم"| usn_journal
    usn_journal -->|"يُتحقّق بـ"| fsutil
    ntfs -->|"يستخدم"| sparse_file
    sparse_file -->|"قد يسبّب"| size_disk_usage_mismatch
    ntfs -->|"يستخدم"| ntfs_compression
    ntfs_compression -->|"قد يسبّب"| size_disk_usage_mismatch
    ntfs_compression -->|"لا يتوافق مع"| asynchronous_io
    ntfs -->|"يُتحقّق بـ"| procmon

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

2. كلّ شيء سجلّ في MFT

2.1. سجلّ المجلّد

حين تُنسَّق مجلّد NTFS، يُنشأ MFT (master file table) ومجموعة ملفّات بيانات وصفيّة تبدأ بـ $. في MFT إدخال واحد على الأقلّ لكلّ ملفّ على المجلّد، ويشمل إدخال MFT نفسه.¹

flowchart TB
    subgraph VOL["مجلّد NTFS"]
        MFT["$MFT ── جدول الملفّات الرئيسيّ<br/>سجلّ سجلات كلّ الملفّات (يحمل نفسه أيضاً)"]
        LOG["$LogFile ── سجلّ معاملات<br/>عمليّات البيانات الوصفيّة (الفصل 6)"]
        BITMAP["$Bitmap ── حالة استخدام العناقيد"]
        OTH["$Boot / $Secure / $UpCase وغيرها<br/>ملفّات بيانات وصفيّة أخرى"]
        DATA["منطقة بيانات المستخدم<br/>(موضع البيانات غير المقيمة)"]
    end
    MFT -->|"السجلّ يشير إلى الموضع"| DATA

الشكل 1: بنية مجلّد NTFS. «معلومات إدارة نظام الملفّات نفسها تُحمَل كملفّات» تصميم NTFS

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

2.2. الملفّ = مجموعة سمات، مقيم وغير مقيم

محتوى سجلّ الملفّ قائمة سمات. معلومات قياسيّة (طوابع زمنيّة وغيرها)، واسم الملفّ، والأمن، ثمّ البيانات. هنا فرع مهمّ.

flowchart TB
    subgraph REC["سجلّ ملفّ MFT (سجلّ ملفّ واحد)"]
        STD["سمة المعلومات القياسيّة<br/>طوابع زمنيّة وأعلام السمات"]
        FN["سمة اسم الملفّ<br/>(يمكن حمل عدّة ── الفصل 4)"]
        DATA["سمة البيانات"]
    end
    Q{"هل البيانات صغيرة"}
    RES["مقيم (resident)<br/>محتوى البيانات يتّسع داخل السجلّ<br/>القراءة تكتمل بوصول MFT فقط"]
    NONRES["غير مقيم (non-resident)<br/>السجلّ لا يحمل إلا «مرجعاً إلى سلسلة عناقيد»<br/>البيانات الفعليّة في منطقة بيانات المستخدم"]
    DATA --> Q
    Q -->|"حتّى بضع مئات من البايتات"| RES
    Q -->|"أكثر من ذلك"| NONRES

الشكل 2: سجلّ الملفّ مجموعة سمات. إن صغرت البيانات «تقيم» داخل السجلّ

يصير أوضح إن صففنا كيف يتغيّر محتوى السجلّ نفسه بين المقيم وغير المقيم.

flowchart LR
    subgraph RES2["مقيم (resident) ── ملفّ صغير"]
        RA["سجلّ ملفّ MFT (طول ثابت)<br/>معلومات قياسيّة / اسم الملفّ / الأمن<br/>─────────────<br/>سمة البيانات = المحتوى نفسه<br/>«القيمة=1» تدخل هنا مباشرة"]
        RB["لا موضع آخر على القرص<br/>القراءة تكتمل بوصول MFT فقط"]
        RA --> RB
    end
    subgraph NON2["غير مقيم (non-resident) ── ملفّ كبير"]
        NA["سجلّ ملفّ MFT (طول ثابت)<br/>معلومات قياسيّة / اسم الملفّ / الأمن<br/>─────────────<br/>سمة البيانات = جدول تشغيلات البيانات<br/>تسلسل «من أين كم عنقوداً»"]
        NB["منطقة بيانات المستخدم<br/>التشغيل 1: عناقيد متّصلة"]
        NC["منطقة بيانات المستخدم<br/>التشغيل 2: عناقيد متّصلة في موضع آخر"]
        NA -->|"يشير إلى الموضع"| NB
        NA -->|"يشير إلى الموضع"| NC
    end

الشكل 3: مقابلة المقيم وغير المقيم. في غير المقيم، ما يحمله السجلّ جدول «أين كم من البيانات الفعليّة» (تشغيلات البيانات) فقط

كلّما زاد عدد تشغيلات البيانات، تصير قراءة ملفّ واحد عبور مناطق متفرّقة. هذه هويّة التفتيت المذكورة تالياً.

من هذه البنية تُفسَّر ظواهر تُصادَف في الميدان.

• سبب بطء نسخ عشرة آلاف ملفّ صغير. لكلّ ملفّ تحدث عمليّات بيانات وصفيّة: إنشاء سجلّ MFT وتسجيل الاسم وإعداد الأمن. عمل السجلّ يصير مهيمناً على نقل البيانات نفسه (وكلّ واحدة منها تصير أيضاً هدفاً لفحص المرشّحات التي نراها في الجزء 6).
• هويّة التفتيت. البيانات غير المقيمة تُسجَّل «كتسلسل نطاقات متّصلة من العناقيد (تشغيلات)». إن تعذّر أخذ نطاق متّصل زاد عدد التشغيلات وزادت التماسات القراءة اللازمة — هذا التفتيت. يمكن الاطّلاع على ترتيب التشغيلات الفعليّ بـ fsutil file layout.
• «المجلّد» ليس خاصّاً. الدليل «ملفّ يحمل فهرساً من اسم الملفّ إلى رقم سجلّ MFT». على السجلّ، الكلّ يركب الآليّة نفسها.

3. البيانات مجرّد «دفق» واحد

3.1. ملفّ واحد، عدّة تسلسلات بايتات

في NTFS يستطيع ملفّ واحد حمل عدّة دفق بيانات. ما تقرأونه وتكتبونه عادة بـ ReadFile/WriteFile هو الدفق الافتراضيّ بلا اسم، ويمكن بتركيب اسم_الملفّ:اسم_الدفق صنع دفق بيانات بديل (ADS).²

flowchart LR
    subgraph F["ملفّ اسمه report.docx (سجلّ MFT واحد)"]
        D0["الدفق الافتراضيّ (بلا اسم)<br/>= المحتوى الذي نراه عادة"]
        D1[":Zone.Identifier<br/>معلومات المصدر (Mark of the Web)"]
        D2[":اسم اختياريّ<br/>معلومات إضافيّة خاصّة بالتطبيق"]
    end

الشكل 4: عدّة دفق بيانات. ما يظهر في عرض الحجم في المستكشف الدفق الافتراضيّ فقط

أقرب ADS هو Zone.Identifier. للملفّات المنزَّلة بالمتصفّح يُسجَّل المصدر (من الإنترنت ونحوه) في هذا الدفق، فيصير مادّة حكم SmartScreen «قامت Windows بحماية جهاز الكمبيوتر الخاص بك» والعرض المحميّ في Office. الجانب الظاهر لهذه الآليّة عولج في «لماذا تظهر رسالة «قامت Windows بحماية جهاز الكمبيوتر الخاص بك» في Windows» — وهويّة الجانب الخلفيّ مجرّد دفق NTFS.

3.2. مطبّات يطؤها المطوّرون

• غير مرئيّ. لا يظهر في حجم المستكشف ولا في قائمة dir. يمكن التحقّق بـ dir /r أو streams من Sysinternals.¹¹
• غير قابل للنقل. ADS ميزة NTFS، لذا تضيع غالباً عند النسخ عبر محرّك USB بـ FAT أو تخزين سحابيّ. «اختفى تحذير التنزيل بعد النسخ» هذا.
• يمكن فتحه من تطبيقكم أيضاً. يكفي تضمين نقطتين في المسار مثل CreateFile("data.txt:meta", ...) للقراءة والكتابة.² مريح، لكنّكم تتولّون خاصّيّة «غير قابل للنقل» في الفقرة السابقة، لذا ليس موضع وضع جوهر بيانات الأعمال.

4. الاسم أيضاً سمة ── الروابط الصلبة وأسماء 8.3

4.1. الرابط الصلب ── عدّة أسماء للسجلّ نفسه

كتبنا في الشكل 2 أنّ «سمة اسم الملفّ يمكن حمل عدّة». داخل المجلّد نفسه، تشير عدّة مسارات إلى ملفّ واحد — هذا الرابط الصلب (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["فهرس C:\app\\"]
        E1["config.json → سجلّ#1234"]
    end
    subgraph DIR2["فهرس C:\backup\\"]
        E2["config-link.json → سجلّ#1234"]
    end
    REC["سجلّ MFT#1234<br/>محتوى البيانات (أو مرجع إلى التشغيلات)<br/>عدد الروابط: 2"]
    E1 --> REC
    E2 --> REC

الشكل 5: الرابط الصلب. فهرس الدليل يشير إلى سجلّ MFT نفسه فحسب، وكلاهما «حقيقيّ»

أيّ اسم تغيّرون منه الملفّ نفسه فالمحتوى يتطابق فوراً.³ ويتغيّر معنى «الحذف» — DeleteFile «ينزع اسماً واحداً»، والكيان لا يختفي إلا حين يُنزَع آخر اسم، وتُغلق المقابض المفتوحة، وتختفي أيضاً كلّ المراجع داخل النواة مثل أقسام تعيين الذاكرة. مرحلتا cleanup (آخر مقبض) وclose (آخر مرجع) اللتان رأيناهما في الجزء 1 تؤثّران كما هما في عمر الحذف. كذلك لعرض السمات طبع، وسلوك مثل تغيير السمة عبر رابط وترك العرض الظاهريّ لروابط أخرى قديماً منصوص رسميّاً.³

4.2. اسم 8.3 ── اسم خفيّ آخر

للتوافق التاريخيّ، يستطيع NTFS توليد اسم مختصر بصيغة 8.3 مثل REPORT~1.DOC تلقائيّاً للأسماء الطويلة. هذا أيضاً يجاور في السجلّ كـ«اسم آخر». في مجلّدات ذات عدد هائل من الملفّات يصير توليد الاسم المختصر وتجنّب التصادم كلفة، لذا يمكن بـ fsutil 8dot3name تعطيل التوليد أو إزالة الأسماء المختصرة القائمة (نقطة عمليّة أنّ هناك وظيفة فحص قبل strip، لأنّ تطبيقاً قديماً يسجّل مسار سجلّ بالاسم المختصر قد ينكسر).⁴

ما ينبغي الانتباه إليه أنّ وجود الاسم المختصر يعتمد على البيئة. السلوك الافتراضيّ يُحسَم بقيمة السجلّ NtfsDisable8dot3NameCreation، وهي أربعة: 0 (توليد على كلّ المجلّدات)، 1 (لا توليد على أيّ مجلّد)، 2 (تعيين لكلّ مجلّد)، 3 (لا توليد إلا خارج مجلّد النظام).⁴ إن اخترتم 2 يمكن التبديل لكلّ مجلّد، لذا لا يصحّ أن «في Windows يوجد حتماً اسم مختصر مثل PROGRA~1». قبل كتابة شيفرة أو إجراء يعتمد على الاسم المختصر، تحقّقوا من الحالة الحاليّة بـ fsutil 8dot3name query C: (حذف المجلّد يعيد الإعداد الافتراضيّ المشترك لكلّ المجلّدات).

مطبّات المسارات والأسماء (MAX_PATH، والأسماء المحجوزة، والنقطة الأخيرة) عولجت تفصيلاً في «MAX_PATH ومطبّات المسارات وأسماء الملفّات في Windows». جمع حلّ الأسماء في الجزء 1 (مدير الكائنات) وهذا الفصل (الأسماء داخل نظام الملفّات) يعطي الصورة الكلّيّة لـ«الاسم» في Windows.

5. نقاط إعادة التحليل ── حيلة «إن فُتح فمكان آخر»

يمكن إرفاق نقطة إعادة تحليل بملفّ أو دليل. الكيان سمة «وسم + بيانات يعرّفها المستخدم». حين يفتح نظام الملفّات ملفّاً بنقطة إعادة تحليل، تُختطَف المعالجة حسب الوسم — يتولّى برنامج تشغيل مرشّح يفهم الوسم المعالجة، أو إن كان وسم إعادة تسمية يُعاد الحلّ بمسار الهدف.⁵

sequenceDiagram
    participant App as التطبيق
    participant IOM as مدير الإدخال/الإخراج
    participant FS as NTFS

    App->>IOM: CreateFile("C:\data\link.txt")
    IOM->>FS: IRP_MJ_CREATE (عالم الجزء 1)
    Note over FS: اكتشاف نقطة إعادة تحليل على الهدف<br/>إعادة الوسم والبيانات
    alt رابط رمزيّ / وصلة (إعادة تسمية)
        FS-->>IOM: «الموضع الحقيقيّ هنا»
        IOM->>FS: إعادة الحلّ بمسار الهدف
    else وسم يديره مرشّح (ملفّات سحابة وغيرها)
        Note over FS: مرشّح يفهم الوسم<br/>يتولّى المعالجة (الجزء 6)
    end

الشكل 6: حلّ نقطة إعادة التحليل. صارت خطّافاً رسميّاً يتقاطع مع عمليّة «الفتح»

فوق هذه الحيلة الواحدة تصطفّ ميزات مألوفة.

• الرابط الرمزيّ (mklink) ── لافتة تحمل مسار الهدف. تستطيع الإشارة إلى مجلّد آخر أو مسار UNC أيضاً.⁶
• الوصلة / نقطة التركيب ── آليّة قديمة تصل دليلاً بموضع على مجلّد محلّيّ آخر.³
• ملفّات OneDrive عند الطلب ── تمثّل ملفّاً ليست بياناته الفعليّة في اليد بنقطة إعادة تحليل، وفي لحظة الفتح ينزّل المرشّح ويقدّم المحتوى. هويّة «يظهر في المستكشف لكن الفتح يشغّل اتصالاً» (آليّة المرشّح نفسها في الجزء 6).

تحذير عمليّ واحد. «ما وراء المسار ليس بالضرورة ذلك الموضع المحلّيّ». أدوات تجتاز الشجرة تكراريّاً تدخل حلقة بالوصلة، ويتضاعف تجميع الحجم، والنسخ الاحتياطيّ يطلق تجسيداً سحابيّاً هائلاً — شيفرة لا تعرف وجود نقاط إعادة التحليل تطأ هذه. مدخل التدابير تأكيد سمة FILE_ATTRIBUTE_REPARSE_POINT في عائلة FindFirstFile.⁵

6. سجلّا تدوين ── $LogFile وUSN

كثيراً ما يُقال «NTFS نظام ملفّات ذو سجلّ تدوين»، لكن لـ NTFS سجلّي تدوين بدورين مختلفين. الخلط يُخطئ قراءة الضمان.

flowchart TB
    subgraph J1["$LogFile ── سجلّ سابق (كي لا ينكسر)"]
        A1["تسجيل عمليّات البيانات الوصفيّة (تحديث سجلّ وإعادة تسمية وغيرها)<br/>في السجلّ قبل التنفيذ"]
        A2["عند بدء التشغيل التالي بعد عطل نظام<br/>إعادة تشغيل السجلّ لاستعادة اتّساق البنية"]
        A1 --> A2
    end
    subgraph J2["سجلّ USN ── تاريخ التغيير (لمعرفة ما تغيّر)"]
        B1["عند كلّ تغيير لملفّ / دليل<br/>تسجيل محتوى التغيير والاسم"]
        B2["أدوات النسخ الاحتياطيّ وفهرس البحث والمزامنة<br/>تدرك «ما تغيّر منذ المرّة السابقة» بلا مسح كامل"]
        B1 --> B2
    end

الشكل 7: سجلّا التدوين. $LogFile «كي لا ينكسر»، وUSN «لمعرفة التغيير»

الفرق في جدول كالتالي.

جدول 2: مقابلة سجلّي التدوين

• $LogFile (سجلّ المعاملات) سجلّ سابق لعمليّات البيانات الوصفيّة. حتّى إن وقع عطل نظام، يستعيد NTFS اتّساق نظام الملفّات تلقائيّاً من هذا السجلّ ومعلومات نقطة التحقّق عند بدء التشغيل التالي.⁷ ما يُحمى هنا البنية. كما رأينا في الجزء 4، محتوى البيانات المتّسخ في الذاكرة المؤقّتة يمكن أن يُفقد عند انقطاع الطاقة — القراءة الصحيحة «المجلّد لا ينكسر. غير أنّ آخر كتابة يمكن أن تختفي».
• سجلّ USN (سجلّ التغيير) سجلّ يسجّل، عند كلّ تغيير لملفّ أو دليل داخل المجلّد، محتوى التغيير واسم المستهدف.⁸ آليّة تلتقط بها النسخ الاحتياطيّ والمفهرسات «ما تغيّر منذ المرّة السابقة فقط» بلا مسح كامل، وتُستخدم أيضاً لتجنّب إعادة بناء الفهرس بعد العطل.⁸ عمليّاً يفيد تذكّر أنّ fsutil usn readjournal يُستخدم في التحقيق كسجلّ مضاهاة يكمّل إفلات FileSystemWatcher («أساسيّات FileSystemWatcher الآمنة»).

7. المتناثر والضغط ── قصّة أنّ لـ«الحجم» اثنين

في NTFS يُدار الطول المنطقيّ للملفّ والمنطقة المخصَّصة فعلاً على حدة. «الحجم» و«الحجم على القرص» في شاشة الخصائص. ممثلان يولّدان الفارق.

الملفّ المتناثر لا يخصّص منطقة حقيقيّة للنطاقات التي تجري أصفاراً ويديرها «ثقوباً».⁹ ملفّ قرص افتراضيّ بحجم منطقيّ 42 غيغابايت يستخدم 500 ميغابايت فقط على القرص — يحدث عاديّاً. قراءة الثقب تُعيد أصفاراً، والكتابة تخصّص بذلك القدر.

flowchart LR
    subgraph L["الملفّ المنطقيّ (الحجم: 1 غيغابايت)"]
        R1["بيانات 10 ميغابايت"]
        H1["ثقب (أصفار) 500 ميغابايت"]
        R2["بيانات 5 ميغابايت"]
        H2["ثقب (أصفار) الباقي"]
    end
    subgraph P["التخصيص على القرص (15 ميغابايت + معلومات إدارة)"]
        A1["تشغيل: كيان R1"]
        A2["تشغيل: كيان R2"]
    end
    R1 --> A1
    R2 --> A2

الشكل 8: الملفّ المتناثر. لا تخصيص لـ«الثقب»، فيفترق الحجم المنطقيّ والحجم على القرص

ضغط NTFS يخزّن البيانات مضغوطة بوحدات ضغط.¹⁰ شفاف ومريح، لكن الكلفة ليست شفّافة — عند كلّ قراءة وكتابة يجري فكّ وإعادة ضغط، ويسهل تقدّم التفتيت أيضاً. وكما رأينا في الفصل 5 من الجزء 2، الوصول إلى ملفّ مضغوط لا يصير لاتزامنيّاً (نظام الملفّات يحوّله إلى تزامنيّ). أحد المواضع التي تُشتبَه حين «جعلناه إدخال/إخراج لاتزامنيّاً لكن هناك ملفّ لا يسرع».

يمكن الحصول على الحجم الفعليّ القائم على التخصيص بـ GetCompressedFileSize. في تحقيق عدم تطابق «مجموع أحجام الملفّات» و«استخدام القرص»، الممارسة الاشتباه بالترتيب في المتناثر والضغط وADS (الفصل 3) وتقريب العناقيد الأربعة.

8. التحقّق بأعينكم

هذه المرّة أيضاً يمكن مراقبة الكلّ على Windows لديكم (بعضها يحتاج امتيازات مدير). نُرفق لكلّ أمر أين تنظرون لتعرفوا ماذا حتّى تحكموا بأنفسكم إن كانت نتيجة التنفيذ صحيحة.

:: عرض دفق البيانات البديلة
dir /r C:\Users\%USERNAME%\Downloads

انظروا هنا: تحت سطر الملفّ العاديّ تصطفّ أسطر مزاحمة بالشكل اسم_الملفّ:Zone.Identifier:$DATA مع طول. إن وُجد هذا السطر فذلك الملفّ يحمل Mark of the Web (الفصل 3). يُرفَق بملفّ منزَّل بالمتصفّح ولا يُرفَق بملفّ صنعتموه بأنفسكم. التنفيذ في الموضعين والمقارنة يوضح وجود ADS.

:: عرض ترتيب الملفّ على MFT (التشغيلات) والسمات
fsutil file layout C:\path\to\file.dat

:: عرض الامتدادات فقط (أمر فرعيّ مذكور في الوثائق الرسميّة)
fsutil file queryextents C:\path\to\file.dat

انظروا هنا: layout يصطفّ لكلّ دفق الحجم وحجم التخصيص، وإن كان غير مقيم قائمة الامتدادات (أزواج VCN وLCN وعدد العناقيد). ملفّ صغير جدّاً بلا أسطر امتداد مقيم (القسم 2.2)، والانقسام على عدّة أسطر يعني تفتيتاً. التنفيذ على ملفّ نصّ بضعة بايتات وملفّ مئات الميغابايتات والمقارنة أقصر طريقة لاستشعار المقيم/غير المقيم.

:: إعداد توليد الاسم المختصر 8.3 والأسماء المختصرة القائمة
fsutil 8dot3name query C:
dir /x

انظروا هنا: query يُعيد ما إذا كان توليد الاسم المختصر مفعَّلاً أو معطَّلاً على ذلك المجلّد (حذف المجلّد يعيد الإعداد الافتراضيّ المشترك لكلّ المجلّدات).⁴ يعرض dir /x عمود الاسم المختصر بجانب الاسم الطويل، لذا عمود فارغ يعني أنّ اسماً مختصراً لم يُصنع. يمكن تأكيد «ليس من المحتوم وجود اسم مختصر» في القسم 4.2 على بيئتكم.

:: حالة سجل USN
fsutil usn queryjournal C:

انظروا هنا: يُعرض معرّف السجلّ، ونطاق USN الساري (First USN / Next USN)، والحجم الأقصى المستهدف (MaximumSize) ووحدة التخصيص (AllocationDelta).¹² إن صنعتم ملفّاً ثمّ نفّذتم مرّة أخرى ينبغي أن يتقدّم Next USN، وهذا تأكيد أنّ «التغيير يُسجَّل». MaximumSize مقياس «إلى أيّ مدى يمكن الرجوع» المذكور في الفصل 6. على مجلّد السجلّ فيه معطَّل يحدث خطأ.

:: تأكيد نقطة إعادة تحليل (الهدف والوسم)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

انظروا هنا: ما يظهر في dir /aL نقاط إعادة تحليل (ما رُفع فيه FILE_ATTRIBUTE_REPARSE_POINT). تُعرض الروابط الرمزيّة والوصلات بنوع مثل <SYMLINKD> <JUNCTION>. يعرض fsutil reparsepoint query قيمة وسم إعادة التحليل، ومسار الهدف إن كان من نوع إعادة التسمية. تحديد هدف ليس نقطة إعادة تحليل يحدث خطأ، لذا حدوث الخطأ نفسه تأكيد أنّ «هذا مجلّد عاديّ».

إن تتبّعتم عمليّات الملفّات بـ Procmon، تسير شخصيّات هذه الحلقة بأسمائها الحقيقيّة (كتابة إلى $LogFile، ومسارات بأسماء دفق، ومعالجة إعادة التحليل). طريقة الاستخدام في «دليل عملي لأداة Process Monitor (ProcMon)».

9. الخلاصة

• مركز NTFS MFT. كلّ ملفّ سجلّ في السجلّ، والمعلومات إمّا «داخل السجلّ» أو «منطقة خارجيّة يشير إليها السجلّ». البيانات الصغيرة مقيمة، والكبيرة مرجع تشغيلات، وبطء معالجة عدد هائل من الملفّات الصغيرة والتفتيت نتائج هذه البنية.¹
• يمكن حمل عدّة دفق بيانات. Zone.Identifier (Mark of the Web) مجرّد ADS، يُرى بـ dir /r، ولا يُنقَل خارج NTFS.²¹¹
• الاسم سمة ويمكن حمل عدّة. الرابط الصلب أسماء بمكانة مساوية للسجلّ نفسه، واسم 8.3 اسم آخر للتوافق. «الحذف = نزع اسم»، واختفاء الكيان حين تختفي آخر الأسماء والمقابض والمراجع داخل النواة (أقسام معيَّنة وغيرها) كلّها.³⁴
• نقطة إعادة التحليل خطّاف رسميّ لـ«الفتح»، والرابط الرمزيّ والوصلة وملفّات عند الطلب تطبيقات لها. شيفرة تجتاز شجرة تحتاج الوعي بـ FILE_ATTRIBUTE_REPARSE_POINT.⁵⁶
• سجلّا تدوين. $LogFile استعادة اتّساق البنية (كي لا ينكسر)، وUSN تاريخ التغيير (ما تغيّر). ليس «ذو سجلّ تدوين لذا البيانات أيضاً آمنة» — ديمومة البيانات تُبنى بأدوات الجزء 4.⁷⁸
• الحجم المنطقيّ والتخصيص شيئان مختلفان. المتناثر والضغط وADS وتقريب العناقيد العوامل الأربعة الكبرى لـ«عدم تطابق الحجم». بما فيه أنّ الملفّ المضغوط لا يصير إدخال/إخراج لاتزامنيّاً، درج تحقيق الأداء.⁹¹⁰

التتمّة الحلقة الأخيرة، الجزء 6 «برامج تشغيل المرشّح والمرشّحات المصغّرة ── لماذا يستطيع Procmon ومسح الفيروسات التقاطع مع الإدخال/الإخراج». كيف يتقاطع مع الإدخال/الإخراج «من يتوسّطون» الذين ظهروا من الجزء 1 بين حين وآخر — مكافحة الفيروسات، وProcmon، وOneDrive، والتشفير. كلمسة أخيرة للسلسلة، نكشف هويّة السكّان الواقفين في فجوات مكدّس الأجهزة.

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

• أعماق إدخال/إخراج Windows (الجزء 1) ── كلّ قراءة وكتابة تصير IRP: الصورة الكلّيّة لنظام الإدخال/الإخراج
• أعماق إدخال/إخراج Windows (الجزء 2) ── الإدخال/الإخراج التزامنيّ واللاتزامنيّ: المعنى الحقيقيّ لـ OVERLAPPED
• أعماق إدخال/إخراج Windows (الجزء 4) ── مدير الذاكرة المؤقّتة: متى يصل WriteFile فعلاً إلى القرص؟
• لماذا تظهر رسالة «قامت Windows بحماية جهاز الكمبيوتر الخاص بك» في Windows
• MAX_PATH ومطبّات المسارات وأسماء الملفّات في Windows ── حدّ 260 حرفاً، الأسماء المحجوزة، النقطة الأخيرة، حساسيّة الأحرف
• كيفيّة استخدام FileSystemWatcher بأمان - الأحداث المفقودة والإشعارات المكرّرة وفخاخ كشف الاكتمال
• مطبّات محرك الشبكة ومسار UNC ── الممارسة العمليّة للتعامل مع خادم الملفّات (المجلّد المشترك) في تطبيقات الأعمال
• دليل عملي لأداة Process Monitor (ProcMon) — تحديد سبب «عدم قراءة الإعدادات» و«ACCESS DENIED» خلال 10 دقائق

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

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

• تطوير تطبيقات Windows
• التحقيق في الأخطاء وتحليل الأسباب الجذريّة
• ترحيل الأصول القائمة والاستفادة منها
• تواصل معنا

روابط مرجعيّة

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

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

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

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

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

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

ما هو MFT (جدول الملفّات الرئيسيّ)؟

بنية البيانات في قلب مجلّد NTFS — سجلّ يحمل إدخالاً واحداً على الأقلّ (سجلّ ملفّ) لكلّ ملفّ على المجلّد، بما فيه إدخال لـ MFT نفسه. كلّ شيء عن الملفّ، من حجمه وطوابعه الزمنيّة وأذون الوصول حتّى محتوى البيانات نفسه، يُحفَظ إمّا داخل إدخال MFT أو في منطقة خارج MFT يشير إليها الإدخال. ملفّ صغير يتّسع بالكامل، بيانات وكلّ شيء، داخل إدخال MFT (مقيم)؛ وملفّ كبير لا يُسجَّل في الإدخال إلا مرجع لتخطيط بياناته (سلسلة عناقيد) (غير مقيم). حذف ملفّ يعلّم إدخاله حرّاً لإعادة الاستخدام، لكن حجم MFT نفسه لا ينكمش قطّ.

ما بيانات «Zone.Identifier» غير المرئيّة المرفقة بالملفّات؟

أحد دفق بيانات NTFS المتعدّدة (دفق بيانات بديل). في NTFS يستطيع ملفّ واحد حمل عدّة تسلسلات بايتات (دفق)؛ ما تقرأونه وتكتبونه عادة هو الدفق الافتراضيّ بلا اسم. يسجّل Windows مصدر الملفّ — أنّه نُزّل من الإنترنت مثلاً — في دفق إضافيّ تحدّدونه بنقطتين، كما في «file.txt:Zone.Identifier». هذا ما يُسمّى «Mark of the Web»، وهو ما يستخدمه SmartScreen والعرض المحميّ في Office دليلاً في أحكامهما. لا تظهر الدفق البديلة في عرض الحجم في المستكشف؛ يمكن التحقّق منها بأمر dir /r أو أداة streams من Sysinternals. يجدر أيضاً ملاحظة أنّها لا تُحفَظ عند النسخ إلى نظام ملفّات غير NTFS مثل FAT.

ما الفرق بين الرابط الصلب والرابط الرمزيّ؟

الرابط الصلب هو «اسم إضافيّ بمكانة مساوية، يشير إلى كيان الملفّ نفسه — سجلّ MFT نفسه». لا يُنشأ إلا داخل المجلّد نفسه، والوصول إلى الملفّ عبر أيّ من أسمائه يعطي الملفّ نفسه، وحذف اسم واحد لا يزيل الملفّ ما دام اسم آخر باقياً. الرابط الرمزيّ «لافتة توجّهكم إلى مسار مختلف»، يُنفَّذ كنقطة إعادة تحليل. لأنّه يحمل مسار الهدف كسلسلة فقط، يستطيع الإشارة إلى مجلّد مختلف أو حتّى موقع بعيد، لكنّه يصير طريقاً مسدوداً إن اختفى الهدف. عمليّاً القاعدة: استخدموا رابطاً صلباً لمشاركة الكيان الأساسيّ (ممّا يغيّر معنى الحذف)، واستخدموا رابطاً رمزيّاً لإعادة توجيه مسار (للنقل أو التحويل).

NTFS نظام ملفّات ذو سجلّ تدوين، فهل يعني ذلك أنّ البيانات تصمد أمام انقطاع الطاقة؟

يلزم فهم ما يُحمى بدقّة. ما يحميه سجلّ معاملات NTFS ($LogFile) هو اتّساق بنية نظام الملفّات (بياناته الوصفيّة). حتّى إن وقع عطل نظام، يستعيد NTFS الاتّساق تلقائيّاً باستخدام السجلّ عند بدء التشغيل التالي، فيمنع وضع المجلّد التالف غير القابل للقراءة. لكن ذلك لا يعني استعادة المحتوى الفعليّ لملفّ كان في منتصف الكتابة. كما رأينا في الجزء 4 من السلسلة، البيانات المتّسخة الجالسة في الذاكرة المؤقّتة تُفقد عند انقطاع الطاقة. لذا الفهم الصحيح «المجلّد لن ينكسر، لكن محتوى آخر كتابة يمكن أن يختفي» — إن احتجتم ديمومة للبيانات نفسها، عليكم بناؤها بأنفسكم، بـ FlushFileBuffers أو WRITE_THROUGH أو تصميم كتابة على مستوى التطبيق مثل الكتابة إلى ملفّ مؤقّت ثمّ إعادة التسمية.

لماذا يختلف «حجم» الملفّ عن «الحجم على القرص»؟

لأنّ NTFS يدير الطول المنطقيّ للملفّ ومساحة القرص المخصَّصة له فعلاً على حدة. حتّى ملفّ عاديّ يُظهر فرقاً لأنّ التخصيص يُقرَّب إلى عناقيد كاملة (4 كيلوبايت افتراضيّاً)، لكن الملفّات المتناثرة والملفّات المضغوطة حيث يتّسع الفارق. ملفّ متناثر لا يخصّص تخزيناً حقيقيّاً للنطاقات التي تجري أصفاراً — يديرها «ثقوباً» — فيمكن تماماً لملفّ بحجم منطقيّ عدّة غيغابايتات أن يستخدم بضعة ميغابايتات فقط على القرص. ملفّ مضغوط لا يُخصَّص له إلا حجمه بعد الضغط. بالمقابل، إن بدا «الحجم على القرص» أكبر، فتقريب العناقيد أو دفق بيانات بديل كثيراً ما يكون السبب.

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

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

غو كومورا

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

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