MFT (मास्टर फ़ाइल टेबल) क्या है?

NTFS वॉल्यूम के हृदय की डेटा संरचना, वॉल्यूम पर हर फ़ाइल के लिए कम से कम एक प्रविष्टि (फ़ाइल रिकॉर्ड) रखने वाला पंजी। MFT स्वयं की प्रविष्टि भी शामिल। फ़ाइल का आकार, टाइमस्टैम्प, पहुँच अनुमति, डेटा सामग्री तक — फ़ाइल की सब जानकारी MFT प्रविष्टि के भीतर या प्रविष्टि द्वारा बताए MFT-बाहर क्षेत्र में संग्रहीत। छोटी फ़ाइल डेटा सहित MFT प्रविष्टि में समाती है (resident); बड़ी फ़ाइल का डेटा स्थान (क्लस्टर क्रम) संदर्भ मात्र प्रविष्टि में दर्ज (non-resident)। फ़ाइल हटाएँ तो प्रविष्टि खाली चिह्नित पुनः उपयोग, पर MFT स्वयं का आकार नहीं सिकुड़ता।

फ़ाइल पर लगा अदृश्य «Zone.Identifier» डेटा क्या है?

NTFS की कई डेटा स्ट्रीम (वैकल्पिक डेटा स्ट्रीम) में से एक। NTFS में एक फ़ाइल कई बाइट अनुक्रम (स्ट्रीम) रख सकती है; रोज़ पढ़ा-लिखा बिना नाम की डिफ़ॉल्ट स्ट्रीम है। «file.txt:Zone.Identifier» जैसे कोलन से निर्दिष्ट अतिरिक्त स्ट्रीम में Windows फ़ाइल का स्रोत (इंटरनेट से डाउनलोड आदि) दर्ज करता है। यही तथाकथित «Mark of the Web», SmartScreen चेतावनी और Office संरक्षित दृश्य का निर्णय सामग्री। वैकल्पिक स्ट्रीम Explorer आकार प्रदर्शन में नहीं आती, dir /r कमांड या Sysinternals streams उपकरण से जाँचें। 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» का असली रूप। छोटी फ़ाइल दस हज़ार कॉपी उसी कुल आकार की एक फ़ाइल से बहुत धीमी क्यों। «NTFS जर्नलिंग है इसलिए निश्चिंत» कहाँ तक सच — सब इसी संरचना से समझाया जा सकता है।

शृंखला «Windows I/O की गहराई» का भाग 5।

इस भाग को पढ़ने की पूर्वापेक्षा: भाग 1 के IRP और डिवाइस स्टैक मूल समझे हों तो पढ़ना आसान। पर अकेले पढ़ने में कठिनाई न हो, लेख में आने वाले पिछले भागों के शब्द पहले परिभाषित।

शब्द	एक पंक्ति में	विस्तार
IRP (I/O Request Packet)	`ReadFile` जैसे API कॉल कर्नेल में बदला «I/O अनुरोध पर्ची»। ड्राइवर यह पर्ची लेकर संसाधित करता है	भाग 1
I/O मैनेजर और डिवाइस स्टैक	IRP बना लक्ष्य डिवाइस तक चढ़े ड्राइवर (स्टैक) को क्रम से सौंपने वाला कर्नेल भाग और वह चढ़ाव	भाग 1
कैश मैनेजर	फ़ाइल सामग्री मेमोरी पर रखकर `WriteFile` सामग्री बाद में एकत्र डिस्क पर लिखने वाला भाग। «लिखते ही डिस्क पर पहुँचा नहीं» का मूल	भाग 4

तालिका 1: इस भाग में पूर्वापेक्षित पिछले भागों के शब्द

एक और, भाग 1 का cleanup (अंतिम हैंडल बंद) और close (कर्नेल संदर्भ सब गए) दो चरण अध्याय 4 की फ़ाइल हटाने की व्याख्या में आते हैं।

1. निष्कर्ष पहले

NTFS का केंद्र MFT (मास्टर फ़ाइल टेबल) है। सब फ़ाइलें MFT में रिकॉर्ड के रूप में पंजी प्रबंधित, फ़ाइल की सब जानकारी «MFT प्रविष्टि के भीतर» या «प्रविष्टि द्वारा बताए MFT-बाहर क्षेत्र» में (अध्याय 2)।¹
फ़ाइल का पदार्थ «गुणों का समूह» है। छोटी फ़ाइल डेटा सहित MFT रिकॉर्ड में समाती है (resident); बड़ी फ़ाइल क्लस्टर क्रम का संदर्भ मात्र रखती है (non-resident)। छोटी फ़ाइलें बड़ी संख्या में धीमी यहीं से (अध्याय 2)।¹
डेटा कई हो सकते हैं (कई डेटा स्ट्रीम)। रोज़ का डेटा «बिना नाम की स्ट्रीम», file.txt:नाम से अतिरिक्त स्ट्रीम। Zone.Identifier (Mark of the Web) का असली रूप (अध्याय 3)।²
नाम भी गुण है। उसी रिकॉर्ड पर कई नाम हार्ड लिंक। 8.3 संक्षिप्त नाम भी «एक और नाम» के रूप में साथ (अध्याय 4)।³⁴
रीपार्स पॉइंट «खोलें तो दूसरी जगह» का आधिकारिक यंत्र है। सिंबॉलिक लिंक, जंक्शन, OneDrive फ़ाइल ऑन डिमांड सब इसी टैग-युक्त डेटा के अनुप्रयोग (अध्याय 5)।⁵⁶
जर्नल दो हैं। $LogFile मेटाडेटा सुसंगति पुनर्प्राप्ति के लिए (न टूटने का राइट-अहेड लॉग), USN जर्नल परिवर्तन इतिहास रिकॉर्ड के लिए (क्या बदला पंजी)। भूमिकाएँ बिलकुल अलग (अध्याय 6)।⁷⁸
«आकार» और «डिस्क पर आकार» अलग वस्तुएँ हैं। स्पार्स फ़ाइल और संपीड़न अंतर पैदा करते हैं। भाग 2 का «संपीड़ित फ़ाइल अतुल्यकालिक नहीं बनती» पृष्ठभूमि भी यहीं (अध्याय 7)।⁹¹⁰

इस लेख का ज्ञान मानचित्र

NTFS का केंद्र MFT (मास्टर फ़ाइल टेबल) है; सब फ़ाइलें MFT में रिकॉर्ड के रूप में पंजी प्रबंधित होती हैं। छोटा डेटा रिकॉर्ड में resident रहता है, बड़ा डेटा क्लस्टर क्रम (डेटा रन) का संदर्भ मात्र रखने वाला non-resident बनता है — यही छोटी फ़ाइलें बड़ी संख्या में धीमी होने और विखंडन का असली रूप है। कई डेटा स्ट्रीम, हार्ड लिंक, 8.3 संक्षिप्त नाम सब «गुणों का समूह» उसी तंत्र के अनुप्रयोग हैं; रीपार्स पॉइंट सिंबॉलिक लिंक से OneDrive फ़ाइल ऑन डिमांड तक सहारा देने वाला «खोलें» का आधिकारिक हुक है। $LogFile संरचना की सुसंगति बचाता है; डेटा सामग्री की स्थायित्व भाग 4 के कैश नियंत्रण उपकरणों से अलग बनानी पड़ती है।

flowchart LR
    accTitle: NTFS आंतरिक संरचना और MFT का ज्ञान मानचित्र
    accDescr: NTFS, MFT, फ़ाइल रिकॉर्ड, resident और non-resident गुण, डेटा रन, विखंडन, कई डेटा स्ट्रीम, 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["डेटा रन"]
    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["अतुल्यकालिक 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/>(non-resident डेटा का स्थान)"]
    end
    MFT -->|"रिकॉर्ड स्थान इंगित करते हैं"| DATA

चित्र 1: NTFS वॉल्यूम की संरचना। «फ़ाइल सिस्टम स्वयं की प्रबंधन जानकारी भी फ़ाइल के रूप में रखता है» NTFS का डिज़ाइन

फ़ाइल की जानकारी — आकार, टाइमस्टैम्प, पहुँच अनुमति, और डेटा सामग्री तक — MFT प्रविष्टि के भीतर संग्रहीत या प्रविष्टि स्थान वर्णित MFT-बाहर क्षेत्र में।¹ फ़ाइल हटाएँ तो प्रविष्टि «खाली» चिह्नित पुनः उपयोग, पर MFT स्वयं नहीं सिकुड़ता। MFT लगातार रखने को MFT ज़ोन क्षेत्र आरक्षित; वॉल्यूम भरते MFT विखंडन शुरू — यह जीवनकाल की बात आधिकारिक दस्तावेज़ में लिखी है।¹

2.2. फ़ाइल = गुणों का समूह, resident और non-resident

फ़ाइल रिकॉर्ड की सामग्री गुणों की सूची है। मानक जानकारी (टाइमस्टैम्प आदि), फ़ाइल नाम, सुरक्षा, और डेटा। यहाँ महत्वपूर्ण शाखा।

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: फ़ाइल रिकॉर्ड गुणों का समूह। डेटा छोटा हो तो रिकॉर्ड में «resident»

उसी रिकॉर्ड की सामग्री resident और non-resident पर कैसे बदलती है, साथ रखने से स्पष्ट।

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: resident और non-resident तुलना। non-resident पर रिकॉर्ड के पास «वास्तविक डेटा कहाँ कितना» तालिका (डेटा रन) मात्र

डेटा रन संख्या बढ़े तो एक फ़ाइल पढ़ने को बिखरे क्षेत्र घूमना पड़ता है। यही आगे विखंडन का असली रूप।

इस संरचना से स्थल पर मिलने वाली कई घटनाएँ समझाई जाती हैं।

छोटी फ़ाइल दस हज़ार कॉपी धीमी क्यों। प्रत्येक फ़ाइल पर MFT रिकॉर्ड बनाना, नाम पंजीकरण, सुरक्षा सेटिंग — मेटाडेटा ऑपरेशन। डेटा स्थानांतरण से पंजी काम प्रबल (और प्रत्येक भाग 6 के फ़िल्टर जाँच का लक्ष्य भी)।
विखंडन का असली रूप। non-resident डेटा «क्लस्टर लगातार खंड (रन) का क्रम» दर्ज। लगातार क्षेत्र न मिले तो रन संख्या बढ़े, पढ़ने को सीक बढ़े — यही विखंडन। रन का वास्तविक क्रम 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 है। ब्राउज़र से डाउनलोड फ़ाइल पर इस स्ट्रीम में स्रोत (इंटरनेट मूल आदि) दर्ज, SmartScreen का «Windows ने PC सुरक्षित किया» और Office संरक्षित दृश्य का निर्णय सामग्री बनता है। इस तंत्र का बाहरी चेहरा «Windows पर «Windows ने PC सुरक्षित किया» क्यों आता है» में है — पीछे का असली रूप साधारण NTFS स्ट्रीम था।

3.2. डेवलपर के जाल

अदृश्य। Explorer आकार में भी dir सूची में भी नहीं। dir /r या Sysinternals streams से जाँचें।¹¹
न ले जाई जा सके। ADS NTFS सुविधा है, FAT USB या क्लाउड स्टोरेज कॉपी पर प्रायः जाती है। «डाउनलोड चेतावनी कॉपी करते गायब» यही।
अपने ऐप से भी खोल सकते हैं। 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 «एक नाम उतारना» है, अंतिम नाम उतरे, खुले हैंडल बंद हों, आगे मेमोरी मैप सेक्शन जैसे कर्नेल संदर्भ भी सब जाएँ तभी पदार्थ मिटता है। भाग 1 का cleanup (अंतिम हैंडल) और close (अंतिम संदर्भ) दो चरण हटाने के जीवनकाल पर भी ज्यों के त्यों लगते हैं। गुण प्रदर्शन की आदत: एक लिंक से गुण बदलें तो अन्य लिंक का दिखावट पुराना रह सकता है — आधिकारिक टिप्पणी।³

4.2. 8.3 नाम — एक और छिपा नाम

ऐतिहासिक संगतता के लिए NTFS लंबे फ़ाइल नाम पर REPORT~1.DOC जैसे 8.3 संक्षिप्त नाम स्वतः बना सकता है। यह भी «एक और नाम» के रूप में रिकॉर्ड में साथ। बड़ी संख्या फ़ाइल वाले फ़ोल्डर पर संक्षिप्त नाम बनाना-टकराव टालना लागत बनता है, इसलिए 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 I/O मैनेजर
    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 में)।

व्यावहारिक सावधानी एक। «पथ के आगे सच में स्थानीय वह स्थान हो, ज़रूरी नहीं»। पुनरावर्ती ट्री घूमने वाले उपकरण जंक्शन पर लूप, आकार सारांश दोहरा, बैकअप क्लाउड पदार्थ बड़ी संख्या में लाए — रीपार्स पॉइंट न जानने वाला कोड ये कदम रखता है। FindFirstFile परिवार का गुण FILE_ATTRIBUTE_REPARSE_POINT जाँच उपाय का द्वार है।⁵

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 जर्नल (परिवर्तन जर्नल) वॉल्यूम में फ़ाइल या निर्देशिका बदले हर बार परिवर्तन सामग्री और लक्ष्य नाम दर्ज करता पंजी है।⁸ बैकअप या इंडेक्सर «पिछली बार से बदला मात्र» पूरा स्कैन बिना लें, विफलता बाद इंडेक्स पुनर्निर्माण टालने को भी।⁸ व्यवहार में FileSystemWatcher चूक («FileSystemWatcher व्यावहारिक मार्गदर्शिका») पूरी करने वाला मिलान पंजी fsutil usn readjournal जाँच में काम आता है, याद रखें।

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 स्ट्रीम-दर आकार, आवंटन आकार, non-resident हो तो एक्सटेंट (VCN · LCN · क्लस्टर संख्या) सूची। एक्सटेंट पंक्ति न हो बहुत छोटी फ़ाइल resident (2.2); कई पंक्तियों में बँटी हो तो विखंडित। कुछ बाइट पाठ फ़ाइल और सैकड़ों MB फ़ाइल चलाकर तुलना resident/non-resident सबसे छोटा अनुभव।

:: 8.3 संक्षिप्त नाम बनाने की सेटिंग और मौजूदा संक्षिप्त नाम
fsutil 8dot3name query C:
dir /x

यहाँ देखें: query उस वॉल्यूम पर संक्षिप्त नाम बनाना सक्षम या अक्षम लौटाता है (वॉल्यूम छोड़ें तो सब वॉल्यूम साझा डिफ़ॉल्ट)।⁴ dir /x लंबे नाम के साथ संक्षिप्त नाम स्तंभ दिखाता है, स्तंभ खाली तो संक्षिप्त नाम नहीं बना। अध्याय 4.2 «संक्षिप्त नाम हो, ज़रूरी नहीं» अपने वातावरण पर पुष्ट करें।

:: USN जर्नल की स्थिति
fsutil usn queryjournal C:

यहाँ देखें: जर्नल ID, वैध 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। सब फ़ाइलें पंजी रिकॉर्ड, जानकारी «रिकॉर्ड में» या «रिकॉर्ड द्वारा बताए बाहरी क्षेत्र» में। छोटा डेटा resident, बड़ा डेटा रन संदर्भ, छोटी फ़ाइलें बड़ी संख्या में धीमी और विखंडन इसी संरचना के परिणाम।¹
डेटा स्ट्रीम कई हो सकती हैं। 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 में कैसे बीच में आते हैं। शृंखला समापन के रूप में डिवाइस स्टैक की दरार में खड़े निवासियों का असली रूप खोलते हैं।

संदर्भ लिंक

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. Sysinternals streams यूटिलिटी 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) — कैश मैनेजर: आपका WriteFile डिस्क तक कब पहुँचता है

Windows कैश मैनेजर चित्रों से समझाने वाली शृंखला का भाग 4। फ़ाइल मैपिंग के रूप में लागू कैश, रीड-अहेड और विलंबित लिखना, FlushFileBuffers ...

लेख पढ़ें

Windows I/O की गहराई (भाग 6, अंतिम) — फ़िल्टर ड्राइवर और मिनीफ़िल्टर: Procmon और वायरस स्कैन I/O में क्यों बीच में आ सकते हैं

Windows फ़िल्टर ड्राइवर और मिनीफ़िल्टर चित्रों से समझाने वाली शृंखला का अंतिम भाग। फ़िल्टर मैनेजर और अल्टिट्यूड, pre/post कॉलबैक, Procmon...

लेख पढ़ें

OneDrive "फ़ाइलें ऑन-डिमांड" और व्यावसायिक ऐप्स — प्लेसहोल्डर जो धारणाएँ तोड़ते हैं और उनसे कैसे निपटें

डेस्कटॉप का CSV नहीं खुलता, या आयात "फ़ाइल नहीं मिली" से विफल होता है — कारण OneDrive का Known Folder Move और फ़ाइलें ऑन-डिमांड हो सकता ह...

लेख पढ़ें

कॉर्पोरेट प्रॉक्सी और Windows ऐप — WinINET, WinHTTP और .NET में प्रॉक्सी रिज़ॉल्यूशन सुलझाना

ब्राउज़र निकल जाता है, पर केवल व्यावसायिक ऐप कॉर्पोरेट प्रॉक्सी पार नहीं कर पाता। कारण आमतौर पर यह होता है कि WinINET, WinHTTP, पर्यावरण ...

लेख पढ़ें

व्यावहारिक मल्टीथ्रेडिंग सर्वोत्तम प्रथाएँ: .NET संस्करण — और थ्रेड जोड़ने से पहले क्या तय करें

मल्टीथ्रेडेड .NET/C# कोड को कभी-कभी क्रैश या हैंग होने से बचाने वाले डिज़ाइन नियमों का व्यावहारिक सार: थ्रेड स्वयं न बनाकर Task पर चलें, ...

लेख पढ़ें

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

Windows ऐप विकास

व्यावसायिक ऐप, डिवाइस एकीकरण और संचार उपकरण, आवश्यकताओं से विकास तक।

सेवा देखें संपर्क करें

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

MFT (मास्टर फ़ाइल टेबल) क्या है?: NTFS वॉल्यूम के हृदय की डेटा संरचना, वॉल्यूम पर हर फ़ाइल के लिए कम से कम एक प्रविष्टि (फ़ाइल रिकॉर्ड) रखने वाला पंजी। MFT स्वयं की प्रविष्टि भी शामिल। फ़ाइल का आकार, टाइमस्टैम्प, पहुँच अनुमति, डेटा सामग्री तक — फ़ाइल की सब जानकारी MFT प्रविष्टि के भीतर या प्रविष्टि द्वारा बताए MFT-बाहर क्षेत्र में संग्रहीत। छोटी फ़ाइल डेटा सहित MFT प्रविष्टि में समाती है (resident); बड़ी फ़ाइल का डेटा स्थान (क्लस्टर क्रम) संदर्भ मात्र प्रविष्टि में दर्ज (non-resident)। फ़ाइल हटाएँ तो प्रविष्टि खाली चिह्नित पुनः उपयोग, पर MFT स्वयं का आकार नहीं सिकुड़ता।
फ़ाइल पर लगा अदृश्य «Zone.Identifier» डेटा क्या है?: NTFS की कई डेटा स्ट्रीम (वैकल्पिक डेटा स्ट्रीम) में से एक। NTFS में एक फ़ाइल कई बाइट अनुक्रम (स्ट्रीम) रख सकती है; रोज़ पढ़ा-लिखा बिना नाम की डिफ़ॉल्ट स्ट्रीम है। «file.txt:Zone.Identifier» जैसे कोलन से निर्दिष्ट अतिरिक्त स्ट्रीम में Windows फ़ाइल का स्रोत (इंटरनेट से डाउनलोड आदि) दर्ज करता है। यही तथाकथित «Mark of the Web», SmartScreen चेतावनी और Office संरक्षित दृश्य का निर्णय सामग्री। वैकल्पिक स्ट्रीम Explorer आकार प्रदर्शन में नहीं आती, dir /r कमांड या Sysinternals streams उपकरण से जाँचें। 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

ब्लॉग पर लौटें

Windows I/O की गहराई (भाग 5) — NTFS आंतरिक संरचना: MFT से समझा फ़ाइल सिस्टम

1. निष्कर्ष पहले

इस लेख का ज्ञान मानचित्र

2. सब कुछ MFT का रिकॉर्ड है

2.1. वॉल्यूम का पंजी

2.2. फ़ाइल = गुणों का समूह, resident और non-resident

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) — कैश मैनेजर: आपका WriteFile डिस्क तक कब पहुँचता है

Windows I/O की गहराई (भाग 6, अंतिम) — फ़िल्टर ड्राइवर और मिनीफ़िल्टर: Procmon और वायरस स्कैन I/O में क्यों बीच में आ सकते हैं

OneDrive "फ़ाइलें ऑन-डिमांड" और व्यावसायिक ऐप्स — प्लेसहोल्डर जो धारणाएँ तोड़ते हैं और उनसे कैसे निपटें

कॉर्पोरेट प्रॉक्सी और Windows ऐप — WinINET, WinHTTP और .NET में प्रॉक्सी रिज़ॉल्यूशन सुलझाना

व्यावहारिक मल्टीथ्रेडिंग सर्वोत्तम प्रथाएँ: .NET संस्करण — और थ्रेड जोड़ने से पहले क्या तय करें

संबंधित विषय

Windows के तकनीकी विषय

इस विषय से जुड़ी सेवाएँ

Windows ऐप विकास

अक्सर पूछे जाने वाले प्रश्न

लेखक की प्रोफ़ाइल

Go Komura