Kedalaman I/O Windows (bagian 5) — struktur internal NTFS: memahami sistem file lewat MFT

Dalam empat bagian sebelumnya, kita melihat bagaimana permintaan I/O mengalir (bagian 1–3) dan bagaimana cache menerimanya (bagian 4). Pada akhirnya permintaan sampai ke sistem file. Kali ini giliran wakil utamanya, NTFS.

Sudut pandangnya berubah. Sampai sekarang pembahasannya dinamis: alur permintaan. Kali ini strukturnya statis: bagaimana data diletakkan di disk. Apa sebenarnya Zone.Identifier tak terlihat pada file unduhan. Mengapa menyalin 10.000 file kecil jauh lebih lambat daripada satu file berukuran total sama. Sejauh mana klaim “NTFS berjurnal jadi aman” itu benar — semuanya bisa dijelaskan dari struktur ini.

Ini bagian 5 seri “Kedalaman I/O Windows”.

Prasyarat bagian ini: menguasai dasar IRP dan device stack dari bagian 1 membuat bacaan lebih mudah. Namun agar artikel ini tetap bisa dibaca mandiri, istilah dari bagian sebelumnya yang muncul di sini didefinisikan lebih dulu.

Tabel 1: Istilah dari bagian sebelumnya yang menjadi prasyarat bagian ini

Satu lagi: dua tahap cleanup (saat handle terakhir ditutup) dan close (saat semua rujukan di dalam kernel hilang) yang dibahas di bagian 1 juga dipakai saat menjelaskan penghapusan file di bab 4.

1. Kesimpulan dulu

• Pusat NTFS adalah MFT (Master File Table). Semua file dikelola sebagai rekaman di dalam MFT. Semua informasi tentang file ada di dalam entri MFT, atau di area di luar MFT yang ditunjuk entri (bab 2).¹
• File pada dasarnya adalah kumpulan atribut. File kecil muat utuh, termasuk datanya, di dalam rekaman MFT (resident). File besar hanya memegang rujukan ke rangkaian cluster (non-resident). Kelambatan pemrosesan massal file kecil bisa dijelaskan dari sini (bab 2).¹
• Data bisa lebih dari satu (beberapa data stream). Data sehari-hari adalah stream tanpa nama, dan stream tambahan bisa dibuat dengan file.txt:nama. Itulah identitas Zone.Identifier (Mark of the Web) (bab 3).²
• Nama juga atribut. Beberapa nama pada rekaman yang sama itulah hard link. Nama pendek 8.3 juga tinggal bersama sebagai satu nama lagi (bab 4).³⁴
• Reparse point adalah mekanisme resmi “buka, lalu ke tempat lain”. Symbolic link, junction, dan Files On-Demand OneDrive semuanya penerapan data bertag ini (bab 5).⁵⁶
• Ada dua jurnal. $LogFile untuk pemulihan konsistensi metadata (log di muka agar tidak rusak), jurnal USN untuk pencatatan riwayat perubahan (buku besar apa yang berubah). Perannya sama sekali berbeda (bab 6).⁷⁸
• “Ukuran” dan “ukuran di disk” adalah hal yang berbeda. File sparse dan kompresi yang menghasilkan kesenjangan. Latar “file terkompresi tidak menjadi asinkron” yang dibahas di bagian 2 juga ada di sini (bab 7).⁹¹⁰

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 35, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Semuanya adalah rekaman MFT

2.1. Buku besar volume

Ketika volume NTFS diformat, MFT (master file table) dan serangkaian file metadata yang namanya diawali $ dibuat. MFT punya setidaknya satu entri untuk setiap file di volume, dan entri MFT itu sendiri juga termasuk.¹

flowchart TB
    subgraph VOL["Volume NTFS"]
        MFT["$MFT ── Master File Table<br/>buku besar rekaman semua file (dirinya sendiri juga tercantum)"]
        LOG["$LogFile ── log transaksi<br/>operasi metadata (bab 6)"]
        BITMAP["$Bitmap ── status pemakaian cluster"]
        OTH["$Boot / $Secure / $UpCase, dan lain-lain<br/>file metadata lain"]
        DATA["Area data pengguna<br/>(tempat data non-resident)"]
    end
    MFT -->|"Rekaman menunjuk posisi"| DATA

Gambar 1: Struktur volume NTFS. Desain NTFS: informasi pengelolaan sistem file sendiri juga dipegang sebagai file

Informasi tentang file — ukuran, cap waktu, izin akses, bahkan isi data — disimpan di dalam entri MFT, atau di area di luar MFT yang posisinya dijelaskan entri MFT.¹ Ketika file dihapus, entri ditandai sebagai “kosong” dan dipakai ulang, tetapi MFT itu sendiri tidak menyusut. Selain itu, agar MFT tetap berurutan, area bernama zona MFT dicadangkan. Ketika volume mulai penuh, fragmentasi MFT dimulai — bahkan soal umur pakai ini pun tertulis di dokumentasi resmi.¹

2.2. File = kumpulan atribut, resident dan non-resident

Isi rekaman file adalah daftar atribut. Informasi standar (cap waktu, dan sebagainya), nama file, keamanan, lalu data. Di sini ada percabangan penting.

flowchart TB
    subgraph REC["Rekaman file MFT (buku besar untuk satu file)"]
        STD["Atribut informasi standar<br/>cap waktu, bendera atribut"]
        FN["Atribut nama file<br/>(bisa lebih dari satu ── bab 4)"]
        DATA["Atribut data"]
    end
    Q{"Apakah datanya kecil"}
    RES["Resident<br/>isi data muat di dalam rekaman<br/>pembacaan selesai hanya dengan akses MFT"]
    NONRES["Non-resident<br/>rekaman hanya memegang rujukan ke rangkaian cluster<br/>data nyata ada di area data pengguna"]
    DATA --> Q
    Q -->|"Sampai sekitar ratusan byte"| RES
    Q -->|"Lebih dari itu"| NONRES

Gambar 2: Rekaman file adalah kumpulan atribut. Jika data kecil, ia resident di dalam rekaman

Membandingkan bagaimana isi rekaman yang sama berubah antara resident dan non-resident membuatnya lebih mudah dipahami.

flowchart LR
    subgraph RES2["Resident ── file kecil"]
        RA["Rekaman file MFT (panjang tetap)<br/>informasi standar / nama file / keamanan<br/>─────────────<br/>atribut data = isinya sendiri<br/>nilai pengaturan=1 masuk langsung di sini"]
        RB["Tidak ada tempat terpisah di disk<br/>pembacaan selesai hanya dengan akses ke MFT"]
        RA --> RB
    end
    subgraph NON2["Non-resident ── file besar"]
        NA["Rekaman file MFT (panjang tetap)<br/>informasi standar / nama file / keamanan<br/>─────────────<br/>atribut data = tabel data run<br/>urutan dari mana, berapa cluster"]
        NB["Area data pengguna<br/>run 1: cluster berurutan"]
        NC["Area data pengguna<br/>run 2: cluster berurutan di tempat lain"]
        NA -->|"Menunjuk posisi"| NB
        NA -->|"Menunjuk posisi"| NC
    end

Gambar 3: Perbandingan resident dan non-resident. Pada non-resident, yang dipegang rekaman hanyalah tabel (data run) tentang di mana dan berapa banyak data nyata berada

Semakin banyak jumlah data run, semakin sering pembacaan satu file harus berpindah ke area yang terpencar. Itulah wujud fragmentasi yang dibahas berikutnya.

Dari struktur ini, sejumlah gejala di lapangan bisa dijelaskan.

• Alasan menyalin 10.000 file kecil lambat. Setiap file memicu operasi metadata: pembuatan rekaman MFT, pendaftaran nama, pengaturan keamanan. Pekerjaan buku besar mendominasi, bukan transfer data itu sendiri (dan setiap operasi itu juga menjadi sasaran pemeriksaan filter yang dibahas di bagian 6).
• Wujud fragmentasi. Data non-resident dicatat sebagai “urutan rentang cluster yang berurutan (run)”. Jika area yang berurutan tidak tersedia, jumlah run bertambah dan seek yang diperlukan untuk membaca ikut bertambah — itulah fragmentasi. Urutan run yang sebenarnya bisa dilihat dengan fsutil file layout.
• Folder pun tidak istimewa. Direktori adalah file yang memegang indeks dari nama file ke nomor rekaman MFT. Di atas buku besar, semuanya memakai mekanisme yang sama.

3. Data hanyalah salah satu stream

3.1. Satu file, beberapa rangkaian byte

Di NTFS, satu file dapat memegang beberapa data stream. Yang biasa dibaca dan ditulis lewat ReadFile/WriteFile adalah stream default tanpa nama. Alternate data stream (ADS) bisa dibuat dengan sintaks nama-file:nama-stream.²

flowchart LR
    subgraph F["File report.docx (satu rekaman MFT)"]
        D0["Stream default (tanpa nama)<br/>= isi yang biasa dilihat"]
        D1[":Zone.Identifier<br/>informasi asal (Mark of the Web)"]
        D2[":nama bebas<br/>informasi tambahan khusus aplikasi"]
    end

Gambar 4: Beberapa data stream. Yang muncul di tampilan ukuran Explorer hanyalah stream default

ADS yang paling akrab adalah Zone.Identifier. Pada file yang diunduh lewat browser, asal file (misalnya berasal dari internet) dicatat di stream ini, lalu menjadi bahan penilaian pesan SmartScreen “Windows telah melindungi PC Anda” dan Protected View Office. Sisi depannya dibahas di “Alasan pesan Windows telah melindungi PC Anda muncul di Windows” — yang di balik layar ternyata hanya stream NTFS biasa.

3.2. Jebakan yang dihadapi pengembang

• Tidak terlihat. Tidak muncul di ukuran Explorer maupun daftar dir. Bisa diperiksa dengan dir /r atau streams dari Sysinternals.¹¹
• Tidak ikut pindah. ADS adalah fitur NTFS, jadi sering hilang saat disalin lewat USB FAT atau penyimpanan cloud. “Peringatan unduhan hilang setelah disalin” biasanya ini.
• Bisa dibuka dari aplikasi sendiri. Cukup sertakan titik dua di jalur, misalnya CreateFile("data.txt:meta", ...).² Praktis, tetapi sifat “tidak ikut pindah” di atas ikut menempel, jadi ini bukan tempat untuk data bisnis yang menjadi isi utama.

4. Nama juga atribut — hard link dan nama 8.3

4.1. Hard link — beberapa nama menuju rekaman yang sama

Di gambar 2 tertulis bahwa atribut nama file bisa lebih dari satu. Beberapa jalur di dalam volume yang sama merujuk ke satu file — itulah hard link (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["Indeks C:\app\"]
        E1["config.json → rekaman #1234"]
    end
    subgraph DIR2["Indeks C:\backup\"]
        E2["config-link.json → rekaman #1234"]
    end
    REC["Rekaman MFT #1234<br/>isi data (atau rujukan ke run)<br/>jumlah tautan: 2"]
    E1 --> REC
    E2 --> REC

Gambar 5: Hard link. Indeks direktori menunjuk rekaman MFT yang sama; keduanya asli

Perubahan lewat nama mana pun adalah file yang sama, jadi isinya langsung cocok.³ Arti “hapus” ikut berubah — DeleteFile berarti “melepas satu nama”. Entitas baru hilang ketika nama terakhir dilepas, handle yang terbuka ditutup, dan rujukan di dalam kernel seperti section memory map juga semuanya hilang. Dua tahap cleanup (handle terakhir) dan close (rujukan terakhir) dari bagian 1 berlaku apa adanya pada umur penghapusan. Tampilan atribut pun punya keanehan: mengubah atribut lewat satu tautan tidak selalu memperbarui tampilan lewat tautan lain, dan perilaku itu dicatat secara resmi.³

4.2. Nama 8.3 — satu nama tersembunyi lagi

Demi kompatibilitas historis, NTFS dapat membuat nama pendek bentuk 8.3 seperti REPORT~1.DOC secara otomatis untuk nama file panjang. Nama ini juga tinggal bersama di rekaman sebagai “satu nama lagi”. Di folder yang berisi banyak file, pembuatan nama pendek dan penghindaran tabrakan menjadi biaya, sehingga fsutil 8dot3name bisa menonaktifkan pembuatan atau menghapus nama pendek yang sudah ada (aplikasi lama yang mencatat jalur registri dengan nama pendek bisa rusak, jadi adanya fitur pemeriksaan sebelum strip adalah poin praktis).⁴

Yang perlu diperhatikan: ada tidaknya nama pendek bergantung pada lingkungan. Perilaku default ditentukan nilai registri NtfsDisable8dot3NameCreation: 0 (buat di semua volume), 1 (jangan buat di semua volume), 2 (atur per volume), 3 (jangan buat kecuali di volume sistem).⁴ Dengan 2, pengaturan bisa diganti per volume, jadi tidak selalu benar bahwa “di Windows pasti ada nama pendek seperti PROGRA~1”. Sebelum menulis kode atau prosedur yang bergantung pada nama pendek, periksa keadaan saat ini dengan fsutil 8dot3name query C: (jika volume dihilangkan, yang dikembalikan adalah pengaturan default bersama untuk semua volume).

Jebakan seputar jalur dan nama (MAX_PATH, nama cadangan, titik di akhir) dibahas lebih rinci di “MAX_PATH dan jebakan jalur serta nama file Windows”. Resolusi nama di Object Manager (bagian 1) plus nama di dalam sistem file (bab ini) bersama-sama membentuk gambaran utuh “nama” di Windows.

5. Reparse point — mekanisme “buka, lalu ke tempat lain”

File atau direktori dapat diberi reparse point. Wujudnya adalah atribut tag + data buatan pengguna. Ketika sistem file membuka file yang punya reparse point, pemrosesan diambil alih sesuai tag — filter driver yang memahami tag itu yang menangani, atau jika tagnya jenis penggantian nama, resolusi diulang dengan jalur tujuan.⁵

sequenceDiagram
    participant App as Aplikasi
    participant IOM as I/O Manager
    participant FS as NTFS

    App->>IOM: CreateFile("C:\data\link.txt")
    IOM->>FS: IRP_MJ_CREATE (dunia bagian 1)
    Note over FS: Reparse point ditemukan pada target<br/>tag dan data dikembalikan
    alt Symbolic link / junction (penggantian nama)
        FS-->>IOM: Lokasi yang sebenarnya di sini
        IOM->>FS: Ulangi resolusi dengan jalur tujuan
    else Tag yang dikelola filter (file cloud, dan sebagainya)
        Note over FS: Filter yang memahami tag<br/>mengambil alih pemrosesan (bagian 6)
    end

Gambar 6: Resolusi reparse point. Ini hook resmi yang menyela operasi “membuka”

Di atas satu mekanisme ini, fitur yang sudah akrab berjajar.

• Symbolic link (mklink) — rambu yang menyimpan jalur tujuan. Bisa menunjuk ke volume lain atau jalur UNC.⁶
• Junction / mount point — mekanisme lama yang menghubungkan direktori ke lokasi di volume lokal lain.³
• Files On-Demand OneDrive — file yang datanya belum ada di perangkat diwakili reparse point; pada saat dibuka, filter mengunduh lalu menyerahkan isinya. Itulah identitas “terlihat di Explorer, tetapi membuka memicu komunikasi” (mekanisme filter sendiri dibahas di bagian 6).

Catatan praktisnya satu. Tujuan suatu jalur belum tentu lokasi lokal tersebut. Alat yang menelusuri pohon secara rekursif bisa berputar di junction, agregasi ukuran menjadi ganda, cadangan memicu materialisasi massal di cloud — kode yang tidak mengenal reparse point akan menemui semua itu. Pintu masuk penanganannya adalah memeriksa atribut FILE_ATTRIBUTE_REPARSE_POINT pada API keluarga FindFirstFile.⁵

6. Dua jurnal — $LogFile dan USN

Sering dikatakan “NTFS adalah sistem file berjurnal”, tetapi NTFS punya dua jurnal dengan peran berbeda. Jika dicampur, jaminan yang dibaca ikut salah.

flowchart TB
    subgraph J1["$LogFile ── log di muka (agar tidak rusak)"]
        A1["Operasi metadata (pembaruan rekaman, ganti nama, dan sebagainya)<br/>dicatat ke log sebelum dijalankan"]
        A2["Pada boot berikutnya setelah kegagalan sistem,<br/>log diputar ulang untuk memulihkan konsistensi struktur"]
        A1 --> A2
    end
    subgraph J2["Jurnal USN ── riwayat perubahan (agar tahu apa yang berubah)"]
        B1["Setiap perubahan pada file/direktori<br/>mencatat isi perubahan dan nama"]
        B2["Alat cadangan, indeks pencarian, dan sinkronisasi<br/>mengetahui apa yang berubah sejak terakhir tanpa memindai seluruh volume"]
        B1 --> B2
    end

Gambar 7: Dua jurnal. $LogFile agar tidak rusak, USN agar mengetahui perubahan

Perbedaannya jika disusun dalam tabel sebagai berikut.

Tabel 2: Perbandingan dua jurnal

• $LogFile (log transaksi) adalah log di muka operasi metadata. Meskipun terjadi kegagalan sistem, NTFS secara otomatis memulihkan konsistensi sistem file dari log ini dan informasi checkpoint pada boot berikutnya.⁷ Yang dilindungi di sini adalah struktur. Seperti yang dibahas di bagian 4, isi data dirty di cache bisa hilang saat daya putus — pembacaan yang benar: “volume tidak rusak. Namun penulisan terakhir masih bisa hilang.”
• Jurnal USN (jurnal perubahan) adalah buku besar yang mencatat isi perubahan dan nama sasaran setiap kali file atau direktori di volume berubah.⁸ Mekanisme ini memungkinkan cadangan dan indexer mengambil “hanya yang berubah sejak terakhir” tanpa memindai seluruh volume, dan juga dipakai untuk menghindari pembangunan ulang indeks setelah kegagalan.⁸ Dalam praktik, berguna diingat bahwa fsutil usn readjournal bisa dipakai sebagai buku besar pencocokan untuk menutupi yang terlewat FileSystemWatcher (“Panduan praktis FileSystemWatcher”).

7. Sparse dan kompresi — ada dua “ukuran”

Di NTFS, panjang logis file dan area yang benar-benar dialokasikan dikelola terpisah. Itulah “ukuran” dan “ukuran di disk” di layar properti. Dua penyebab utama kesenjangan:

File sparse tidak mengalokasikan ruang nyata ke rentang nol yang beruntun; rentang itu dikelola sebagai “lubang”.⁹ File disk virtual berukuran logis 42 GB yang di disk hanya memakai 500 MB — hal itu biasa terjadi. Membaca lubang mengembalikan nol; menulis ke lubang mengalokasikan sebesar yang ditulis.

flowchart LR
    subgraph L["File logis (ukuran: 1 GB)"]
        R1["Data 10 MB"]
        H1["Lubang (nol) 500 MB"]
        R2["Data 5 MB"]
        H2["Lubang (nol) sisanya"]
    end
    subgraph P["Alokasi di disk (15 MB + informasi pengelolaan)"]
        A1["Run: entitas R1"]
        A2["Run: entitas R2"]
    end
    R1 --> A1
    R2 --> A2

Gambar 8: File sparse. Lubang tidak punya alokasi, sehingga ukuran logis dan ukuran di disk menyimpang

Kompresi NTFS menyimpan data yang dikompresi per unit kompresi.¹⁰ Transparan dan praktis, tetapi biayanya tidak transparan — setiap baca-tulis menjalankan ekspansi dan kompresi ulang, dan fragmentasi juga lebih mudah maju. Lalu, seperti yang dibahas di bagian 2 bab 5, akses ke file terkompresi tidak menjadi asinkron (sistem file mengubahnya menjadi sinkron). Ini salah satu tempat yang perlu dicurigai ketika “sudah dibuat I/O asinkron tetapi ada file yang tidak menjadi cepat”.

Ukuran nyata berbasis alokasi bisa diambil dengan GetCompressedFileSize. Dalam investigasi “jumlah ukuran file” tidak cocok dengan “pemakaian disk”, urutan baku yang dicurigai adalah empat ini: sparse, kompresi, ADS (bab 3), dan pembulatan cluster.

8. Periksa dengan mata sendiri

Kali ini pun semuanya bisa diamati di Windows yang ada di tangan (sebagian memerlukan hak administrator). Agar hasil eksekusi bisa dinilai sendiri, setiap perintah dilengkapi catatan di mana dilihat dan apa yang diketahui.

:: Melihat alternate data stream
dir /r C:\Users\%USERNAME%\Downloads

Lihat di sini: Di bawah baris file biasa, baris menjorok berbentuk nama-file:Zone.Identifier:$DATA berjajar beserta panjangnya. Jika baris itu ada, file tersebut membawa Mark of the Web (bab 3). File yang diunduh lewat browser memilikinya; file yang dibuat sendiri tidak. Menjalankan perintah di kedua lokasi lalu membandingkan membuat ada tidaknya ADS menjadi jelas.

:: Melihat tata letak (run) dan atribut file di MFT
fsutil file layout C:\path\to\file.dat

:: Melihat extent saja (subcommand yang tercantum di dokumentasi resmi)
fsutil file queryextents C:\path\to\file.dat

Lihat di sini: layout merinci per stream ukuran, ukuran alokasi, dan jika non-resident, daftar extent (pasangan VCN, LCN, jumlah cluster). File sangat kecil yang tidak mengeluarkan baris extent adalah resident (pasal 2.2); jika terpecah ke beberapa baris, file itu terfragmentasi. Cara tercepat merasakan resident versus non-resident adalah menjalankan perintah pada file teks beberapa byte dan file ratusan MB, lalu membandingkannya.

:: Pengaturan pembuatan nama pendek 8.3 dan nama pendek yang sudah ada
fsutil 8dot3name query C:
dir /x

Lihat di sini: query mengembalikan apakah pembuatan nama pendek di volume itu aktif atau nonaktif (jika volume dihilangkan, yang dikembalikan adalah pengaturan default bersama untuk semua volume).⁴ dir /x menampilkan kolom nama pendek di samping nama panjang, jadi kolom kosong berarti nama pendek tidak dibuat. “Nama pendek tidak selalu ada” di pasal 4.2 bisa dicek di lingkungan sendiri.

:: Status jurnal USN
fsutil usn queryjournal C:

Lihat di sini: ID jurnal, rentang USN yang valid (First USN / Next USN), ukuran target (MaximumSize), dan satuan alokasi (AllocationDelta) ditampilkan.¹² Setelah membuat sebuah file lalu menjalankan lagi, Next USN seharusnya maju — itu konfirmasi bahwa perubahan sedang dicatat. MaximumSize adalah patokan “sejauh mana bisa ditelusuri mundur” yang disinggung di bab 6. Pada volume yang jurnalnya nonaktif, perintah menghasilkan galat.

:: Memeriksa reparse point (tujuan tautan dan tag)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

Lihat di sini: Yang muncul di dir /aL adalah reparse point (yang FILE_ATTRIBUTE_REPARSE_POINT-nya menyala). Symbolic link dan junction ditampilkan beserta jenis seperti <SYMLINKD> <JUNCTION>. fsutil reparsepoint query menampilkan nilai reparse tag, dan jika jenis penggantian nama, jalur tujuan. Menunjuk ke sasaran yang bukan reparse point menghasilkan galat, jadi galat itu sendiri adalah konfirmasi “ini folder biasa”.

Jika operasi file dilacak dengan Procmon, nama-nama yang dibahas di sini muncul apa adanya (penulisan ke $LogFile, jalur yang memuat nama stream, pemrosesan reparse). Cara memakainya ada di “Panduan praktis Process Monitor (ProcMon)”.

9. Ringkasan

• Pusat NTFS adalah MFT. Semua file adalah rekaman di buku besar; informasi ada “di dalam rekaman” atau “di area eksternal yang ditunjuk rekaman”. Data kecil resident, data besar rujukan run, dan kelambatan pemrosesan massal file kecil serta fragmentasi adalah akibat struktur ini.¹
• Data stream bisa lebih dari satu. Zone.Identifier (Mark of the Web) hanyalah ADS; terlihat dengan dir /r, dan tidak ikut terbawa ke luar NTFS.²¹¹
• Nama adalah atribut, dan bisa lebih dari satu. Hard link adalah nama setara menuju rekaman yang sama; nama 8.3 adalah nama tambahan untuk kompatibilitas. “Hapus = melepas nama”; entitas baru hilang ketika nama terakhir, handle, dan rujukan di dalam kernel (section yang sudah di-map, dan sebagainya) semuanya tiada.³⁴
• Reparse point adalah hook resmi ke “membuka”, dan symbolic link, junction, serta Files On-Demand semuanya penerapannya. Kode yang menelusuri pohon perlu memperhatikan FILE_ATTRIBUTE_REPARSE_POINT.⁵⁶
• Jurnal ada dua. $LogFile memulihkan konsistensi struktur (agar tidak rusak), USN adalah riwayat perubahan (apa yang berubah). “Berjurnal jadi datanya juga aman” tidak benar — ketahanan data dibangun dengan alat di bagian 4.⁷⁸
• Ukuran logis dan alokasi adalah hal berbeda. Sparse, kompresi, ADS, dan pembulatan cluster adalah empat penyebab utama “ukuran tidak cocok”. Termasuk soal file terkompresi yang tidak menjadi I/O asinkron, ini menjadi bekal investigasi kinerja.⁹¹⁰

Lanjutannya adalah bagian terakhir, bagian 6 “Filter driver dan minifilter — alasan Procmon dan pemindaian virus bisa menyela I/O”. “Yang menyelip di tengah” yang muncul berkali-kali sejak bagian 1 — perlindungan virus, Procmon, OneDrive, enkripsi — bagaimana mereka menyela I/O. Sebagai penutup seri, identitas penghuni yang berdiri di celah device stack akan diungkap.

Artikel terkait

• Kedalaman I/O Windows (bagian 1) — semua baca-tulis menjadi IRP: gambaran utuh sistem I/O
• Kedalaman I/O Windows (bagian 2) — I/O sinkron dan I/O asinkron: arti sebenarnya OVERLAPPED
• Kedalaman I/O Windows (bagian 4) — Cache Manager: kapan WriteFile Anda sampai ke disk
• Alasan pesan “Windows telah melindungi PC Anda” muncul di Windows
• MAX_PATH dan jebakan jalur serta nama file Windows — batas 260 karakter, nama cadangan, titik di akhir, huruf besar-kecil
• Panduan praktis FileSystemWatcher — penanganan yang terlewat dan duplikat
• Jebakan network drive dan jalur UNC — praktik menangani file server (folder berbagi) di aplikasi bisnis
• Panduan praktis Process Monitor (ProcMon) — mengidentifikasi “pengaturan tidak dibaca” dan “ACCESS DENIED” dalam 10 menit

Area konsultasi terkait

Di Komura Soft, kami menangani perancangan dan investigasi aplikasi bisnis Windows yang berakar pada mekanisme NTFS — perilaku aneh ukuran file atau kinerja salin, serta gangguan terkait tautan dan stream.

• Pengembangan aplikasi Windows
• Investigasi bug dan analisis penyebab
• Pemanfaatan aset yang ada dan dukungan migrasi
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa itu MFT (Master File Table)?

Struktur data inti volume NTFS — buku besar yang memegang setidaknya satu entri (rekaman file) untuk setiap file di volume, termasuk entri MFT itu sendiri. Semua informasi tentang file — ukuran, cap waktu, izin akses, sampai isi data — disimpan di dalam entri MFT, atau di area di luar MFT yang ditunjuk entri tersebut. File kecil muat utuh, termasuk datanya, di dalam entri MFT (resident). File besar hanya mencatat rujukan ke lokasi data (rangkaian cluster) di entri (non-resident). Menghapus file menandai entri sebagai kosong agar bisa dipakai ulang, tetapi ukuran MFT sendiri tidak menyusut.

Apa data tak terlihat Zone.Identifier yang menempel pada file?

Salah satu dari beberapa data stream NTFS (alternate data stream). Di NTFS, satu file dapat memegang beberapa rangkaian byte (stream). Yang biasa dibaca dan ditulis adalah stream default tanpa nama. Windows mencatat asal file — misalnya bahwa file diunduh dari internet — di stream tambahan yang ditentukan dengan titik dua, seperti file.txt:Zone.Identifier. Itulah yang disebut Mark of the Web, dan menjadi bahan penilaian peringatan SmartScreen serta Protected View Office. Stream alternatif tidak muncul di tampilan ukuran Explorer; bisa diperiksa dengan perintah dir /r atau alat streams dari Sysinternals. Perlu diperhatikan juga bahwa stream ini tidak dipertahankan jika disalin ke sistem file selain NTFS, misalnya FAT.

Apa perbedaan hard link dan symbolic link?

Hard link berarti satu nama setara lagi ditambahkan, yang menunjuk ke entitas file yang sama (rekaman MFT yang sama). Hard link hanya dapat dibuat di dalam volume yang sama. Mengakses file lewat nama mana pun memberi file yang sama, dan menghapus satu nama tidak menghapus file selama nama lain masih ada. Symbolic link adalah rambu yang mengarahkan ke jalur lain, diimplementasikan sebagai reparse point. Karena hanya menyimpan string jalur tujuan, ia dapat menunjuk ke volume lain atau lokasi remote, tetapi menjadi jalan buntu jika tujuan hilang. Dalam praktik, hard link dipakai untuk berbagi entitas yang sama (arti penghapusan ikut berubah), sedangkan symbolic link dipakai untuk mengalihkan jalur (pemindahan atau pengalihan).

NTFS adalah sistem file berjurnal, jadi apakah data selamat dari pemutusan daya?

Yang dilindungi perlu dipahami dengan tepat. Log transaksi NTFS ($LogFile) melindungi konsistensi struktur sistem file (metadata). Jika terjadi kegagalan sistem, NTFS secara otomatis memulihkan konsistensi memakai log pada boot berikutnya, sehingga terhindar dari situasi volume rusak dan tidak dapat dibaca. Namun isi data file yang sedang ditulis tidak ikut dipulihkan. Seperti yang dibahas di bagian 4 seri ini, data dirty di cache hilang saat daya putus. Pemahaman yang benar: volume tidak rusak, tetapi isi penulisan terakhir masih bisa hilang. Jika ketahanan data itu sendiri diperlukan, hal itu harus dibangun sendiri — dengan FlushFileBuffers, WRITE_THROUGH, atau desain penulisan di sisi aplikasi seperti tulis ke file sementara lalu ganti nama.

Mengapa ukuran file berbeda dari ukuran di disk?

Karena NTFS mengelola panjang logis file dan ruang disk yang benar-benar dialokasikan secara terpisah. Bahkan file biasa bisa berbeda karena alokasi dibulatkan ke cluster utuh (default 4 KB), tetapi kesenjangan membesar pada file sparse dan file terkompresi. File sparse tidak mengalokasikan ruang nyata ke rentang nol yang beruntun — rentang itu dikelola sebagai lubang — sehingga file dengan ukuran logis beberapa gigabyte bisa hanya memakai beberapa megabyte di disk. File terkompresi hanya dialokasikan sebesar ukuran setelah kompresi. Sebaliknya, jika ukuran di disk tampak lebih besar, penyebabnya sering pembulatan cluster atau alternate data stream.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.