MFT (Master File Table) คืออะไร?

โครงสร้างข้อมูลที่เป็นหัวใจของวอลุ่ม NTFS คือสมุดทะเบียนที่มีอย่างน้อยหนึ่งรายการ (เรกคอร์ดไฟล์) สำหรับทุกไฟล์บนวอลุ่ม รวมรายการของ MFT เองด้วย ข้อมูลทั้งหมดเกี่ยวกับไฟล์ ตั้งแต่ขนาด การประทับเวลา สิทธิ์เข้าถึง ไปจนเนื้อหาข้อมูลเอง ถูกเก็บในรายการ MFT หรือในพื้นที่นอก MFT ที่รายการชี้ไป ไฟล์เล็กพอจะเก็บตัวข้อมูลทั้งก้อนในรายการ MFT (เรซิเดนต์) ไฟล์ใหญ่มีแค่การอ้างอิงไปที่วางข้อมูล (แถวคลัสเตอร์) ถูกบันทึกในรายการ (นอนเรซิเดนต์) เมื่อลบไฟล์ รายการถูกทำเครื่องหมายว่างเพื่อใช้ใหม่ แต่ขนาดของ MFT เองไม่หด

ข้อมูลที่มองไม่เห็นชื่อ «Zone.Identifier» ที่ติดไฟล์คืออะไร?

เป็นหนึ่งในสตรีมข้อมูลหลายอันของ NTFS (สตรีมข้อมูลสำรอง) ใน NTFS ไฟล์หนึ่งไฟล์มีลำดับไบต์ (สตรีม) ได้หลายอัน สิ่งที่อ่านเขียนปกติคือสตรีมเริ่มต้นที่ไม่มีชื่อ Windows บันทึกแหล่งที่มาของไฟล์ (ดาวน์โหลดจากอินเทอร์เน็ต ฯลฯ) ในสตรีมเพิ่มที่ระบุด้วยเครื่องหมายทวิภาคอย่าง «file.txt:Zone.Identifier» นี่คือที่เรียก «Mark of the Web» และเป็นวัตถุดิบการตัดสินของคำเตือน SmartScreen และมุมมองที่ป้องกันของ Office สตรีมสำรองไม่โผล่ในการแสดงขนาดของ Explorer ตรวจได้ด้วยคำสั่ง dir /r หรือเครื่องมือ streams ของ Sysinternals จุดที่ต้องระวังคือ เมื่อคัดลอกไประบบไฟล์ที่ไม่ใช่ NTFS (FAT ฯลฯ) จะไม่ถูกเก็บ

ฮาร์ดลิงก์กับลิงก์สัญลักษณ์ต่างกันอย่างไร?

ฮาร์ดลิงก์คือ «ชื่อระดับเดียวกันอีกอันที่ชี้ตัวจริงไฟล์เดียวกัน (เรกคอร์ด MFT เดียวกัน) ถูกเพิ่ม» สร้างได้แค่ในวอลุ่มเดียวกัน เข้าถึงจากชื่อใดก็เป็นไฟล์เดียวกัน และลบชื่อหนึ่ง ถ้ายังมีชื่ออื่นอยู่ ไฟล์ไม่หาย ลิงก์สัญลักษณ์คือ «ป้ายที่ชี้ไปพาธอื่น» ถูกอิมพลีเมนต์เป็นจุดรีพาร์ส เพราะถือแค่สตริงพาธปลายทาง จึงชี้วอลุ่มอื่นหรือระยะไกลได้ แต่ถ้าปลายทางหายจะตัน ในงานจริง หลักคือฮาร์ดลิงก์ใช้แชร์ตัวจริง (ความหมายของการลบเปลี่ยน) ลิงก์สัญลักษณ์ใช้เปลี่ยนพาธ (ย้ายหรือเปลี่ยนทิศ)

NTFS เป็นระบบไฟล์แบบวารสาร งั้นตัดไฟข้อมูลก็ไม่หายหรือ?

ต้องเข้าใจขอบที่ถูกป้องกันให้ถูก สิ่งที่ล็อกธุรกรรมของ NTFS ($LogFile) ป้องกันคือความสอดคล้องของโครงสร้างระบบไฟล์ (เมทาดาตา) แม้ระบบล้ม ตอนบูตครั้งถัดไปใช้ล็อกกู้ความสอดคล้องอัตโนมัติ กันสถานการณ์ «วอลุ่มพังอ่านไม่ได้» แต่ไม่ได้หมายความว่าเนื้อหาข้อมูลของไฟล์ที่กำลังเขียนอยู่ถูกกู้ ตามที่เห็นในตอนที่ 4 ของซีรีส์ ข้อมูลสกปรกบนแคชหายเมื่อตัดไฟ ดังนั้นความเข้าใจที่ถูกคือ «วอลุ่มไม่พัง แต่เนื้อหาการเขียนครั้งสุดท้ายอาจหาย» ถ้าต้องการความทนทานของข้อมูลเอง ต้องสร้างด้วย FlushFileBuffers, WRITE_THROUGH หรือการออกแบบการเขียนฝั่งแอป (ไฟล์ชั่วคราว+เปลี่ยนชื่อ ฯลฯ)

เชิงลึกของ Windows I/O (ตอนที่ 5) — โครงสร้างภายในของ NTFS: เข้าใจระบบไฟล์จาก MFT

29 Jul 2026 05:00 · Go Komura · Windows, NTFS, I/O, ระบบไฟล์, MFT, เคอร์เนล, .NET, การสอบสวนบั๊ก

สี่ตอนที่ผ่านมา เราดูว่าคำขอ I/O ไหลอย่างไร (ตอนที่ 1〜3) และแคชรับอย่างไร (ตอนที่ 4) คำขอไปถึง ระบบไฟล์ เป็นที่สุด คราวนี้ถึงตาตัวแทนนั้น คือ NTFS

มุมเปลี่ยน ถึงตอนนี้เป็นเรื่อง พลวัต คือ «กระแสของคำขอ» คราวนี้เป็นเรื่องโครงสร้าง สถิต คือ ข้อมูลถูกวางบนดิสก์อย่างไร ตัวจริงของ «Zone.Identifier» ที่มองไม่เห็นซึ่งติดไฟล์ที่ดาวน์โหลด เหตุที่คัดลอกไฟล์เล็ก 10,000 ไฟล์ช้ากว่าไฟล์เดียวขนาดรวมเท่ากันมากแค่ไหน «NTFS เป็นแบบวารสารจึงสบายใจ» จริงแค่ไหน ── อธิบายได้ทั้งหมดจากโครงสร้างนี้

เป็นตอนที่ 5 ของซีรีส์ «เชิงลึกของ Windows I/O»

ข้อสมมติของการอ่านตอนนี้: ถ้าจับพื้นฐาน IRP กับสแตกอุปกรณ์ของตอนที่ 1 แล้วจะอ่านง่าย อย่างไรก็ตาม เพื่อให้อ่านเดี่ยวได้ จะนิยามคำจากตอนก่อนที่โผล่ในบทความก่อน

คำ	พูดหนึ่งบรรทัด	รายละเอียด
IRP (I/O Request Packet)	«ใบคำขอ I/O» ที่การเรียก API อย่าง `ReadFile` ถูกแปลงในเคอร์เนล ไดรเวอร์รับใบนี้แล้วประมวลผล	ตอนที่ 1
I/O Manager กับสแตกอุปกรณ์	ส่วนของเคอร์เนลที่สร้าง IRP แล้วส่งตามลำดับไปไดรเวอร์ที่กองจนถึงอุปกรณ์เป้าหมาย และกองนั้นเอง	ตอนที่ 1
Cache Manager	ส่วนที่ถือเนื้อหาไฟล์ในหน่วยความจำ แล้วเขียนเนื้อหาของ `WriteFile` ไปดิสก์ทีหลังรวม ๆ ต้นเหตุของ «เพิ่งเขียนไม่ได้แปลว่าไปถึงดิสก์แล้ว»	ตอนที่ 4

ตาราง 1: คำจากตอนก่อนที่ใช้เป็นข้อสมมติในตอนนี้

อีกอย่าง สองขั้นที่จัดการในตอนที่ 1 คือ cleanup (เมื่อแฮนเดิลสุดท้ายปิด) และ close (เมื่อการอ้างอิงในเคอร์เนลหายหมด) ถูกใช้ในคำอธิบายการลบไฟล์ของหมวด 4 ด้วย

1. สรุปก่อนเลย

ศูนย์กลางของ NTFS คือ MFT (Master File Table) ไฟล์ทั้งหมดถูกจัดการเป็นเรกคอร์ดในสมุดทะเบียนใน 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 (Master File Table) และไฟล์ทั้งหมดถูกจัดการเป็นเรกคอร์ดในสมุดทะเบียนใน MFT ข้อมูลเล็กเป็นเรซิเดนต์ในเรกคอร์ด ข้อมูลใหญ่เป็นนอนเรซิเดนต์ที่ถือแค่การอ้างอิงไปแถวคลัสเตอร์ (ดาต้ารัน) และนี่คือตัวจริงของความช้าในการประมวลผลไฟล์เล็กจำนวนมากและการแตกกระจาย สตรีมข้อมูลหลายอัน ฮาร์ดลิงก์ และชื่อสั้น 8.3 ล้วนเป็นการประยุกต์กลไกเดียวกันคือ «ชุดแอตทริบิวต์» และจุดรีพาร์สคือตะขอทางการของ «เปิด» ที่รองรับตั้งแต่ลิงก์สัญลักษณ์จนถึงไฟล์ตามความต้องการของ OneDrive สิ่งที่ $LogFile ป้องกันคือความสอดคล้องของโครงสร้าง ความทนทานของเนื้อหาข้อมูลต้องสร้างแยกด้วยเครื่องมือควบคุมแคชของตอนที่ 4

flowchart LR
    accTitle: แผนที่ความรู้โครงสร้างภายในของ NTFS กับ MFT
    accDescr: แผนภาพที่แสดงความสัมพันธ์ระหว่าง NTFS, MFT, เรกคอร์ดไฟล์, แอตทริบิวต์เรซิเดนต์กับนอนเรซิเดนต์, ดาต้ารัน, การแตกกระจาย, สตรีมข้อมูลหลายอัน, Zone.Identifier, ฮาร์ดลิงก์, ชื่อสั้น 8.3, จุดรีพาร์ส (ลิงก์สัญลักษณ์・จังก์ชัน・ไฟล์ตามความต้องการของ OneDrive), $LogFile กับวารสาร USN, ไฟล์สปาร์สและการบีบอัด NTFS
    ntfs["NTFS"]
    mft["MFT (Master File Table)"]
    mft_record["เรกคอร์ดไฟล์ MFT"]
    mft_zone["โซน MFT"]
    fragmentation["การแตกกระจาย (NTFS)"]
    resident_attribute["แอตทริบิวต์เรซิเดนต์ (resident)"]
    non_resident_attribute["แอตทริบิวต์นอนเรซิเดนต์ (non-resident)"]
    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["Cache Manager"]
    usn_journal["วารสาร USN (วารสารการเปลี่ยน)"]
    sparse_file["ไฟล์สปาร์ส"]
    ntfs_compression["การบีบอัด NTFS"]
    asynchronous_io["I/O แบบอะซิงโครนัส"]
    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 ถูกจองไว้ และเมื่อวอลุ่มเริ่มเต็ม การแตกกระจายของ 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: เทียบเรซิเดนต์กับนอนเรซิเดนต์ ในนอนเรซิเดนต์ สิ่งที่เรกคอร์ดมีคือแค่ตาราง (ดาต้ารัน) ว่า «ข้อมูลจริงอยู่ที่ไหนกี่อัน»

ยิ่งจำนวนดาต้ารันเพิ่ม การอ่านไฟล์หนึ่งไฟล์ยิ่งต้องเดินข้ามพื้นที่ที่กระจาย นี่คือตัวจริงของการแตกกระจายที่กล่าวต่อไป

จากโครงสร้างนี้ อธิบายปรากฏการณ์ที่เจอในงานได้หลายอย่าง

เหตุที่คัดลอกไฟล์เล็ก 10,000 ไฟล์ช้า แต่ละไฟล์เกิดการดำเนินการเมทาดาตา คือสร้างเรกคอร์ด 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: สตรีมข้อมูลหลายอัน สิ่งที่โผล่ในการแสดงขนาดของ Explorer คือแค่สตรีมเริ่มต้น

ADS ที่ใกล้ที่สุดคือ Zone.Identifier ไฟล์ที่ดาวน์โหลดด้วยเบราว์เซอร์ มีแหล่งที่มา (มาจากอินเทอร์เน็ต ฯลฯ) ถูกบันทึกในสตรีมนี้ และเป็นวัตถุดิบการตัดสินของ «พีซีถูกปกป้องโดย Windows» ของ SmartScreen และมุมมองที่ป้องกันของ Office หน้าของกลไกนี้อยู่ใน «เหตุผลที่ Windows แสดง «พีซีถูกปกป้องโดย Windows»» ── ตัวจริงด้านหลังคือแค่สตรีม NTFS

3.2. กับดักที่นักพัฒนาเหยียบ

มองไม่เห็น ไม่โผล่ทั้งขนาดของ Explorer และรายการ 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 (Object Manager) กับหมวดนี้ (ชื่อในระบบไฟล์) จะได้ภาพรวมของ «ชื่อ» ของ Windows

5. จุดรีพาร์ส — กลไก «เปิดแล้วไปที่อื่น»

ไฟล์หรือไดเรกทอรีติด จุดรีพาร์ส ได้ ตัวจริงคือแอตทริบิวต์ «แท็ก + ข้อมูลที่ผู้ใช้กำหนด» เมื่อระบบไฟล์เปิดไฟล์ที่มีจุดรีพาร์ส การประมวลผลถูกแย่ง ตามแท็ก ── ไดรเวอร์ฟิลเตอร์ที่เข้าใจแท็กรับการประมวลผล หรือถ้าเป็นแท็กชนิดเปลี่ยนชื่อ การแก้จะถูกทำใหม่ด้วยพาธปลายทาง⁵

sequenceDiagram
    participant App as แอป
    participant IOM as I/O Manager
    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 ── แสดงไฟล์ที่ยังไม่มีข้อมูลจริงในมือเป็นจุดรีพาร์ส และวินาทีที่ถูกเปิด ฟิลเตอร์ดาวน์โหลดแล้วส่งเนื้อใน นี่คือตัวจริงของ «เห็นใน Explorer แต่เปิดแล้วมีการสื่อสาร» (กลไกของฟิลเตอร์เองอยู่ในตอนที่ 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 เพื่อ «รู้การเปลี่ยน»

ความต่างเมื่อทำตาราง เป็นดังนี้

มุม	`$LogFile` (ล็อกธุรกรรม)	วารสาร USN (วารสารการเปลี่ยน)
จุดประสงค์	คืน โครงสร้าง ของระบบไฟล์สู่สถานะสอดคล้องหลังล้ม⁷	รู้ทีหลังว่า «อะไรเปลี่ยนจากครั้งก่อน»⁸
สิ่งที่บันทึก	ล็อกล่วงหน้าของการดำเนินการเมทาดาตา (อัปเดตเรกคอร์ด・เปลี่ยนชื่อ ฯลฯ) เนื้อในไฟล์อยู่นอกเป้า	ทุกครั้งที่เปลี่ยน เนื้อหาการเปลี่ยนกับชื่อไฟล์/ไดเรกทอรีเป้า⁸
ใครใช้	NTFS เอง ใช้กู้อัตโนมัติตอนเมานต์ครั้งถัดไป	แอปอย่างสำรอง ดัชนีค้นหา เครื่องมือซิงค์
ย้อนได้ไกลแค่ไหน	แค่ช่วงที่ต้องใช้กู้ ใช้ขนาดคงที่วน จึงใช้ไล่ประวัติไม่ได้	เมื่อเกินขนาดเป้าหมาย (MaximumSize) เรกคอร์ดเก่าถูกตัดตอนจุดตรวจ ช่วงที่ย้อนได้ขึ้นกับการตั้งขนาดและปริมาณอัปเดตของวอลุ่ม¹²
วิธีอ้างอิง	ไม่มีวิธีทางการอ่านเนื้อใน (ขนาดตรวจด้วย `chkdsk /L` ได้)	สถานะด้วย `fsutil usn queryjournal` เนื้อในด้วย `fsutil usn readjournal` จากโปรแกรมใช้ `FSCTL_QUERY_USN_JOURNAL` / `FSCTL_READ_USN_JOURNAL`¹²
หยุดได้ไหม	หยุดไม่ได้ (เป็นส่วนของ NTFS)	ผู้ดูแลลบหรือปิดได้ แต่บังคับบริการที่ใช้อยู่ให้สแกนทั้งก้อน ผลจึงใหญ่¹²

ตาราง 2: เทียบสองวารสาร

$LogFile (ล็อกธุรกรรม) คือ ล็อกล่วงหน้า ของการดำเนินการเมทาดาตา แม้ระบบล้ม NTFS กู้ความสอดคล้องของระบบไฟล์อัตโนมัติ จากล็อกนี้กับข้อมูลจุดตรวจตอนบูตครั้งถัดไป⁷ สิ่งที่ถูกป้องกันตรงนี้คือ โครงสร้าง ตามที่เห็นในตอนที่ 4 เนื้อหาข้อมูล สกปรกบนแคชอาจหายเมื่อตัดไฟ ── «วอลุ่มไม่พัง แต่การเขียนครั้งสุดท้ายอาจหาย» คือการอ่านที่ถูก
วารสาร USN (วารสารการเปลี่ยน) คือสมุดทะเบียนที่บันทึก เนื้อหาการเปลี่ยนกับชื่อเป้า ทุกครั้งที่ไฟล์หรือไดเรกทอรีในวอลุ่มเปลี่ยน⁸ เป็นกลไกให้สำรองหรืออินเด็กเซอร์เก็บ «เฉพาะที่เปลี่ยนจากครั้งก่อน» โดยไม่สแกนทั้งก้อน และถูกใช้เลี่ยงการสร้างดัชนีใหม่หลังล้มด้วย⁸ ในงานจริง จำไว้ว่าใช้ fsutil usn readjournal เป็นสมุดทะเบียนจับคู่เสริมการตกหล่นของ FileSystemWatcher («คู่มือปฏิบัติ FileSystemWatcher») ตอนสอบสวน จะมีประโยชน์

7. สปาร์สกับการบีบอัด — เรื่องที่ «ขนาด» มีสองอัน

ใน NTFS ความยาวเชิงตรรกะ ของไฟล์กับ พื้นที่ที่ถูกจัดสรรจริง ถูกจัดการแยก คือ «ขนาด» กับ «ขนาดบนดิสก์» ในหน้าคุณสมบัติ ตัวแทนที่สร้างความห่างมีสองอย่าง

ไฟล์สปาร์ส ไม่จัดสรรพื้นที่จริงให้ช่วงที่เป็นศูนย์ต่อเนื่อง จัดการเป็น «หลุม»⁹ ไฟล์ดิสก์เสมือนขนาดตรรกะ 42GB ใช้บนดิสก์แค่ 500MB ── เกิดเป็นเรื่องปกติ อ่านหลุมได้ศูนย์ เขียนแล้วถูกจัดสรรเฉพาะส่วนนั้น

flowchart LR
    subgraph L["ไฟล์เชิงตรรกะ (ขนาด: 1GB)"]
        R1["ข้อมูล 10MB"]
        H1["หลุม (ศูนย์) 500MB"]
        R2["ข้อมูล 5MB"]
        H2["หลุม (ศูนย์) ที่เหลือ"]
    end
    subgraph P["การจัดสรรบนดิสก์ (15MB+ข้อมูลจัดการ)"]
        A1["รัน: ตัวจริงของ R1"]
        A2["รัน: ตัวจริงของ R2"]
    end
    R1 --> A1
    R2 --> A2

ภาพ 8: ไฟล์สปาร์ส «หลุม» ไม่มีการจัดสรร ขนาดตรรกะกับขนาดบนดิสก์ห่างกัน

การบีบอัด NTFS บีบอัดข้อมูลทีละหน่วยบีบอัดแล้วเก็บ¹⁰ โปร่งใสและสะดวก แต่ต้นทุนก็ไม่โปร่งใส ── ทุกครั้งที่อ่านเขียนมีการขยายและบีบอัดใหม่ และการแตกกระจายก็เกิดง่ายขึ้น และตามที่เห็นใน ตอนที่ 2 หมวด 5 การเข้าถึงไฟล์บีบอัดไม่อะซิงค์ (ระบบไฟล์แปลงเป็นซิงค์) เมื่อ «ทำให้เป็น I/O อะซิงค์แล้วแต่มีไฟล์ที่ไม่เร็วขึ้น» นี่คือที่หนึ่งที่ควรสงสัย

ขนาดจริงฐานการจัดสรรดึงด้วย 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) ถ้าแยกหลายแถวแสดงว่าแตกกระจาย วิธีสัมผัสเรซิเดนต์/นอนเรซิเดนต์ที่สั้นที่สุดคือรันเทียบไฟล์ข้อความไม่กี่ไบต์กับไฟล์หลายร้อย MB

:: การตั้งค่าการสร้างชื่อสั้น 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 การปัดคลัสเตอร์ คือสี่ปัจจัยใหญ่ของ «ขนาดไม่ตรง» รวมเรื่องไฟล์บีบอัดที่ไม่อะซิงค์ I/O เป็นลิ้นชักของการสอบสวนสมรรถนะ⁹¹⁰

ต่อคือตอนสุดท้าย ตอนที่ 6 «ไดรเวอร์ฟิลเตอร์กับมินิฟิลเตอร์ ── เหตุที่ Procmon และการสแกนไวรัสแทรก I/O ได้» «ผู้ที่แทรกกลาง» ที่โผล่เป็นระยะตั้งแต่ตอนที่ 1 ── ป้องกันไวรัส Procmon OneDrive การเข้ารหัส ── แทรก I/O อย่างไร ในฐานะการเก็บงานซีรีส์ จะเปิดตัวจริงของผู้อยู่ที่ยืนในช่องว่างของสแตกอุปกรณ์

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับงานออกแบบและสอบสวนแอปธุรกิจ Windows ที่รากอยู่ในกลไกของ NTFS เช่น พฤติกรรมขนาดไฟล์หรือสมรรถนะการคัดลอกที่อธิบายยาก บั๊กรอบลิงก์และสตรีม

ลิงก์อ้างอิง

Microsoft Learn, Master File Table. ว่าด้วยทุกไฟล์บนวอลุ่ม NTFS ที่มีอย่างน้อยหนึ่งรายการใน MFT รวมรายการของ MFT เอง ข้อมูลทั้งหมดรวมขนาด การประทับเวลา สิทธิ์เข้าถึง เนื้อหาข้อมูล ที่ถูกเก็บในรายการ MFT หรือในพื้นที่นอก MFT ที่รายการบรรยายตำแหน่ง เมื่อลบไฟล์รายการถูกทำเครื่องหมายว่างเพื่อใช้ใหม่แต่ขนาด MFT ไม่หด โซน MFT ที่ถูกจองเพื่อรักษา MFT ให้ต่อเนื่อง และการแตกกระจายของ MFT ที่เกิดเมื่อการจัดสรรเดินหน้า ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, File Streams. ว่าด้วยข้อมูลไฟล์ของ NTFS ที่ถูกเก็บเป็นสตรีมหนึ่งอันขึ้นไป สตรีมข้อมูลเริ่มต้น (ไม่มีชื่อ) กับสตรีมข้อมูลสำรองที่มีชื่อ และการเปิดสตรีมด้วย CreateFile โดยระบุรูป «ชื่อไฟล์:ชื่อสตรีม» ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Hard links and junctions. ว่าด้วยฮาร์ดลิงก์ที่เป็นการแสดงบนระบบไฟล์ที่หลายพาธในวอลุ่มเดียวกันอ้างอิงไฟล์เดียว การสร้างด้วย CreateHardLink การเปลี่ยนผ่านลิงก์ใดที่เห็นจากลิงก์อื่นทันที นิสัยการแสดงที่การเปลี่ยนแอตทริบิวต์แพร่ไปทุกฮาร์ดลิงก์ แต่การแสดงบนรายการไดเรกทอรีถูกอัปเดตเฉพาะลิงก์ที่ทำการเปลี่ยน และจังก์ชัน (กลไกที่เชื่อมไดเรกทอรีไปวอลุ่มท้องถิ่นอื่น) ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, fsutil 8dot3name. ว่าด้วย NTFS ที่สร้างชื่อสั้นรูปแบบ 8.3 ให้ชื่อไฟล์ยาวได้ fsutil 8dot3name ที่สอบถามและตั้งการเปิด/ปิดการสร้างชื่อสั้น ถอด (strip) ชื่อสั้นที่มีอยู่ และสแกนการอ้างอิงรีจิสทรีที่จะได้รับผลเมื่อถอด ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Reparse points. ว่าด้วยจุดรีพาร์สที่เป็นชุดของข้อมูลที่ผู้ใช้กำหนดกับแท็กรีพาร์สที่ระบุรูปแบบข้อมูลนั้นไม่ซ้ำ เมื่อเปิดไฟล์ที่มีจุดรีพาร์ส ระบบไฟล์พยายามประมวลผลที่ตรงแท็ก (การประมวลผลโดยฟิลเตอร์ระบบไฟล์ที่ตีความแท็ก) ถูกใช้ในอิมพลีเมนต์ลิงก์ระบบไฟล์ของ NTFS และที่เก็บระยะไกล (หน่วยความจำแบบชั้น) และตรวจการมีด้วยแอตทริบิวต์ FILE_ATTRIBUTE_REPARSE_POINT ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Symbolic links. ว่าด้วยลิงก์สัญลักษณ์ที่เป็นอ็อบเจ็กต์ระบบไฟล์ที่ชี้ไฟล์หรือไดเรกทอรีอื่น และทำงานเป็นการเปลี่ยนทิศโปร่งใสสู่ปลายทาง มีลิงก์สัมบูรณ์และสัมพัทธ์ และอ้างอิงข้ามวอลุ่มหรือพาธระยะไกลได้ ↩ ↩² ↩³
Microsoft Learn, NTFS overview. ว่าด้วย NTFS ที่ใช้ไฟล์ล็อกกับข้อมูลจุดตรวจ และเมื่อระบบล้ม จะเล่นล็อกธุรกรรมซ้ำตอนบูตครั้งถัดไปเพื่อกู้ความสอดคล้องของระบบไฟล์อัตโนมัติ การรีแมปเซกเตอร์เสียแบบพลวัต และ self-healing NTFS ที่ซ่อมความเสียหายเล็กน้อยในพื้นหลัง ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Change Journals. ว่าด้วยทุกครั้งที่ไฟล์หรือไดเรกทอรีในวอลุ่มถูกเปลี่ยน เนื้อหาการเปลี่ยนกับชื่อไฟล์/ไดเรกทอรีเป้าถูกบันทึกในวารสารการเปลี่ยน USN ของวอลุ่มนั้น วารสารถูกรักษาทีละวอลุ่ม และใช้กู้ดัชนีระบบไฟล์หลังล้มได้ โดยเลี่ยงการทำดัชนีวอลุ่มทั้งก้อนใหม่ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Sparse Files. ว่าด้วยไฟล์สปาร์สที่ไม่จัดสรรพื้นที่ดิสก์กายภาพให้ช่วงใหญ่ที่ประกอบด้วยศูนย์ และจัดสรรพื้นที่เฉพาะส่วนที่มีข้อมูล การอ่านช่วงที่ไม่มีจัดสรรคืนศูนย์ ↩ ↩² ↩³
Microsoft Learn, File Compression and Decompression. ว่าด้วยการบีบอัดไฟล์ของ NTFS ที่ทำโปร่งใส ข้อมูลถูกบีบอัดและเก็บทีละหน่วยบีบอัด GetCompressedFileSize ที่ดึงขนาดหลังบีบอัด (จัดสรรจริง) ได้ และการอ่านเขียนไฟล์บีบอัดที่มาพร้อมต้นทุนขยายและบีบอัดใหม่ ↩ ↩² ↩³
Microsoft Learn, Streams - Sysinternals. ว่าด้วยยูทิลิตี streams ของ Sysinternals ที่แจกและลบสตรีมข้อมูลสำรองของไฟล์ NTFS ได้ ↩ ↩²
Microsoft Learn, Creating, Modifying, and Deleting a Change Journal และ fsutil usn. ว่าด้วย MaximumSize ของวารสารการเปลี่ยนที่เป็นค่าเป้าหมาย และเมื่อขนาดเกินผลรวม MaximumSize กับ AllocationDelta จะถูกตัดตอนจุดตรวจของ NTFS AllocationDelta ที่เป็นหน่วยการเพิ่มท้ายวารสารและการลบจากต้น fsutil usn queryjournal ที่อ้างอิงสถานะและความจุของวารสาร และ readjournal ที่อ้างอิงเนื้อหาที่บันทึก จากโปรแกรมใช้ FSCTL_CREATE_USN_JOURNAL / FSCTL_QUERY_USN_JOURNAL / FSCTL_READ_USN_JOURNAL / FSCTL_DELETE_USN_JOURNAL และการลบหรือปิดวารสารที่ทำงานอยู่ที่มาพร้อมการสแกน MFT ทั้งก้อน และบังคับบริการที่ใช้วารสารให้สแกนวอลุ่มใหม่ ↩ ↩² ↩³ ↩⁴

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

เชิงลึกของ Windows I/O (ตอนที่ 4) — Cache Manager: WriteFile ของคุณไปถึงดิสก์เมื่อใด

ตอนที่ 4 ของซีรีส์ที่อธิบาย Cache Manager ของ Windows ด้วยแผนภาพ จัดแคชที่อิมพลีเมนต์เป็นการแมปไฟล์ การอ่านล่วงหน้ากับการเขียนแบบหน่วง กา...

อ่านบทความ

เชิงลึกของ Windows I/O (ตอนที่ 6・ตอนสุดท้าย) — ไดรเวอร์ฟิลเตอร์กับมินิฟิลเตอร์: เหตุที่ Procmon และการสแกนไวรัสแทรก I/O ได้

ตอนสุดท้ายของซีรีส์ที่อธิบายไดรเวอร์ฟิลเตอร์และมินิฟิลเตอร์ของ Windows ด้วยแผนภาพ ครอบ Filter Manager กับอัลติจูด คอลแบ็ก pre/post กลไกที...

อ่านบทความ

OneDrive "ไฟล์ตามความต้องการ" กับแอปธุรกิจ — ข้อสมมติที่เพลสโฮลเดอร์ทำลาย และวิธีรับมือ

CSV บนเดสก์ท็อปเปิดไม่ได้ หรือการนำเข้าล้มเหลวด้วย "ไม่พบไฟล์" — สาเหตุอาจเป็น Known Folder Move และไฟล์ตามความต้องการของ OneDrive บทความ...

อ่านบทความ

พร็อกซีองค์กรและแอป Windows — จัดระเบียบการหาพร็อกซีใน WinINET, WinHTTP และ .NET

เบราว์เซอร์ผ่านได้ แต่มีแค่แอปธุรกิจที่ข้ามพร็อกซีองค์กรไม่ได้ สาเหตุมักเป็นการไม่ตรงกันของค่าพร็อกซีที่ WinINET, WinHTTP, ตัวแปรสภาพแวดล...

อ่านบทความ

แนวปฏิบัติมัลติเธรดเชิงปฏิบัติ: ฉบับ .NET — สิ่งที่ต้องตัดสินก่อนเพิ่มเธรด

เรียบเรียงหลักออกแบบที่กันไม่ให้โค้ดมัลติเธรด .NET/C# «แครชหรือค้างเป็นครั้งคราว»: อย่าสร้างเธรดเอง ให้ขี่ Task ลดสถานะที่เปลี่ยนแปลงร่วม...

อ่านบทความ

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

หัวข้อเทคนิคของ Windows

ประตูสู่การพัฒนา Windows การตรวจสอบบั๊ก และการใช้ประโยชน์จากสินทรัพย์เดิม

ดูหัวข้อ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

พัฒนาแอป Windows

แอปธุรกิจ การเชื่อมต่ออุปกรณ์ และเครื่องมือสื่อสาร ตั้งแต่ความต้องการจนถึงการพัฒนา

ดูบริการ ติดต่อเรา

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

MFT (Master File Table) คืออะไร?: โครงสร้างข้อมูลที่เป็นหัวใจของวอลุ่ม NTFS คือสมุดทะเบียนที่มีอย่างน้อยหนึ่งรายการ (เรกคอร์ดไฟล์) สำหรับทุกไฟล์บนวอลุ่ม รวมรายการของ MFT เองด้วย ข้อมูลทั้งหมดเกี่ยวกับไฟล์ ตั้งแต่ขนาด การประทับเวลา สิทธิ์เข้าถึง ไปจนเนื้อหาข้อมูลเอง ถูกเก็บในรายการ MFT หรือในพื้นที่นอก MFT ที่รายการชี้ไป ไฟล์เล็กพอจะเก็บตัวข้อมูลทั้งก้อนในรายการ MFT (เรซิเดนต์) ไฟล์ใหญ่มีแค่การอ้างอิงไปที่วางข้อมูล (แถวคลัสเตอร์) ถูกบันทึกในรายการ (นอนเรซิเดนต์) เมื่อลบไฟล์ รายการถูกทำเครื่องหมายว่างเพื่อใช้ใหม่ แต่ขนาดของ MFT เองไม่หด
ข้อมูลที่มองไม่เห็นชื่อ «Zone.Identifier» ที่ติดไฟล์คืออะไร?: เป็นหนึ่งในสตรีมข้อมูลหลายอันของ NTFS (สตรีมข้อมูลสำรอง) ใน NTFS ไฟล์หนึ่งไฟล์มีลำดับไบต์ (สตรีม) ได้หลายอัน สิ่งที่อ่านเขียนปกติคือสตรีมเริ่มต้นที่ไม่มีชื่อ Windows บันทึกแหล่งที่มาของไฟล์ (ดาวน์โหลดจากอินเทอร์เน็ต ฯลฯ) ในสตรีมเพิ่มที่ระบุด้วยเครื่องหมายทวิภาคอย่าง «file.txt:Zone.Identifier» นี่คือที่เรียก «Mark of the Web» และเป็นวัตถุดิบการตัดสินของคำเตือน SmartScreen และมุมมองที่ป้องกันของ Office สตรีมสำรองไม่โผล่ในการแสดงขนาดของ Explorer ตรวจได้ด้วยคำสั่ง dir /r หรือเครื่องมือ streams ของ Sysinternals จุดที่ต้องระวังคือ เมื่อคัดลอกไประบบไฟล์ที่ไม่ใช่ NTFS (FAT ฯลฯ) จะไม่ถูกเก็บ
ฮาร์ดลิงก์กับลิงก์สัญลักษณ์ต่างกันอย่างไร?: ฮาร์ดลิงก์คือ «ชื่อระดับเดียวกันอีกอันที่ชี้ตัวจริงไฟล์เดียวกัน (เรกคอร์ด MFT เดียวกัน) ถูกเพิ่ม» สร้างได้แค่ในวอลุ่มเดียวกัน เข้าถึงจากชื่อใดก็เป็นไฟล์เดียวกัน และลบชื่อหนึ่ง ถ้ายังมีชื่ออื่นอยู่ ไฟล์ไม่หาย ลิงก์สัญลักษณ์คือ «ป้ายที่ชี้ไปพาธอื่น» ถูกอิมพลีเมนต์เป็นจุดรีพาร์ส เพราะถือแค่สตริงพาธปลายทาง จึงชี้วอลุ่มอื่นหรือระยะไกลได้ แต่ถ้าปลายทางหายจะตัน ในงานจริง หลักคือฮาร์ดลิงก์ใช้แชร์ตัวจริง (ความหมายของการลบเปลี่ยน) ลิงก์สัญลักษณ์ใช้เปลี่ยนพาธ (ย้ายหรือเปลี่ยนทิศ)
NTFS เป็นระบบไฟล์แบบวารสาร งั้นตัดไฟข้อมูลก็ไม่หายหรือ?: ต้องเข้าใจขอบที่ถูกป้องกันให้ถูก สิ่งที่ล็อกธุรกรรมของ NTFS ($LogFile) ป้องกันคือความสอดคล้องของโครงสร้างระบบไฟล์ (เมทาดาตา) แม้ระบบล้ม ตอนบูตครั้งถัดไปใช้ล็อกกู้ความสอดคล้องอัตโนมัติ กันสถานการณ์ «วอลุ่มพังอ่านไม่ได้» แต่ไม่ได้หมายความว่าเนื้อหาข้อมูลของไฟล์ที่กำลังเขียนอยู่ถูกกู้ ตามที่เห็นในตอนที่ 4 ของซีรีส์ ข้อมูลสกปรกบนแคชหายเมื่อตัดไฟ ดังนั้นความเข้าใจที่ถูกคือ «วอลุ่มไม่พัง แต่เนื้อหาการเขียนครั้งสุดท้ายอาจหาย» ถ้าต้องการความทนทานของข้อมูลเอง ต้องสร้างด้วย FlushFileBuffers, WRITE_THROUGH หรือการออกแบบการเขียนฝั่งแอป (ไฟล์ชั่วคราว+เปลี่ยนชื่อ ฯลฯ)
ทำไม «ขนาด» ของไฟล์กับ «ขนาดบนดิสก์» จึงต่าง?: เพราะใน NTFS ความยาวเชิงตรรกะของไฟล์กับพื้นที่ดิสก์ที่ถูกจัดสรรจริงถูกจัดการแยก แม้ไฟล์ปกติก็ต่างเพราะจัดสรรปัดขึ้นเป็นหน่วยคลัสเตอร์ (ค่าเริ่มต้น 4KB) แต่ที่ห่างมากคือไฟล์สปาร์สกับไฟล์บีบอัด ไฟล์สปาร์สไม่จัดสรรพื้นที่จริงให้ช่วงที่เป็นศูนย์ต่อเนื่อง จัดการเป็น «หลุม» จึงเกิดได้ที่ขนาดตรรกะหลาย GB แต่บนดิสก์แค่ไม่กี่ MB ไฟล์บีบอัดถูกจัดสรรแค่ขนาดหลังบีบอัด ในทางกลับกัน ถ้า «ขนาดบนดิสก์» ดูใหญ่กว่า สาเหตุอาจเป็นการปัดคลัสเตอร์หรือสตรีมข้อมูลสำรอง

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก

ดูโปรไฟล์ ติดต่อเรา

ลิงก์สาธารณะ

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

กลับไปยังบล็อก

1. สรุปก่อนเลย

แผนที่ความรู้ของบทความนี้

2. ทุกอย่างคือเรกคอร์ดของ MFT

2.1. สมุดทะเบียนของวอลุ่ม

2.2. ไฟล์ = ชุดแอตทริบิวต์ เรซิเดนต์กับนอนเรซิเดนต์

3. ข้อมูลเป็นแค่หนึ่งใน «สตรีม»

3.1. หนึ่งไฟล์ หลายลำดับไบต์

3.2. กับดักที่นักพัฒนาเหยียบ

4. ชื่อก็เป็นแอตทริบิวต์ — ฮาร์ดลิงก์กับชื่อ 8.3

4.1. ฮาร์ดลิงก์ — หลายชื่อสู่เรกคอร์ดเดียวกัน

4.2. ชื่อ 8.3 — อีกชื่อที่ซ่อน

5. จุดรีพาร์ส — กลไก «เปิดแล้วไปที่อื่น»

6. สองวารสาร — $LogFile กับ USN

7. สปาร์สกับการบีบอัด — เรื่องที่ «ขนาด» มีสองอัน

8. ยืนยันด้วยตาตนเอง

9. สรุป

บทความที่เกี่ยวข้อง

ด้านให้คำปรึกษาที่เกี่ยวข้อง

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

เชิงลึกของ Windows I/O (ตอนที่ 4) — Cache Manager: WriteFile ของคุณไปถึงดิสก์เมื่อใด

เชิงลึกของ Windows I/O (ตอนที่ 6・ตอนสุดท้าย) — ไดรเวอร์ฟิลเตอร์กับมินิฟิลเตอร์: เหตุที่ Procmon และการสแกนไวรัสแทรก I/O ได้

OneDrive "ไฟล์ตามความต้องการ" กับแอปธุรกิจ — ข้อสมมติที่เพลสโฮลเดอร์ทำลาย และวิธีรับมือ

พร็อกซีองค์กรและแอป Windows — จัดระเบียบการหาพร็อกซีใน WinINET, WinHTTP และ .NET

แนวปฏิบัติมัลติเธรดเชิงปฏิบัติ: ฉบับ .NET — สิ่งที่ต้องตัดสินก่อนเพิ่มเธรด

หัวข้อที่เกี่ยวข้อง

หัวข้อเทคนิคของ Windows

บริการที่เกี่ยวข้องกับหัวข้อนี้

พัฒนาแอป Windows

คำถามที่พบบ่อย

โปรไฟล์ผู้เขียน

Go Komura