Windows I/O की गहराई (भाग 5) — NTFS internals: MFT से समझा file system

पिछले चार भागों में I/O request कैसे बहता है (भाग 1–3) और cache कैसे ग्रहण करता है (भाग 4) देखा। Request अंत में file system तक पहुँचता है। इस बार उसका प्रतिनिधि NTFS की बारी।

दृष्टि बदलती है। अब तक «request का प्रवाह» dynamic कथा थी। इस बार disk पर data कैसे रखा है — static structure की कथा। Download file पर लगा अदृश्य «Zone.Identifier» का असली रूप। छोटी file दस हज़ार copy उसी कुल size की एक file से बहुत धीमी क्यों। «NTFS journaling है इसलिए निश्चिंत» कहाँ तक सच — सब इसी structure से समझाया जा सकता है।

Series «Windows I/O की गहराई» का भाग 5।

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

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

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

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

• NTFS का केंद्र MFT (Master File Table) है। सब files MFT में records के रूप में catalog managed, file की सब जानकारी «MFT entry के भीतर» या «entry द्वारा बताए MFT-बाहर क्षेत्र» में (अध्याय 2)।¹
• File का पदार्थ «attributes का समूह» है। छोटी file data सहित MFT record में समाती है (resident); बड़ी file cluster sequence का reference मात्र रखती है (non-resident)। छोटी files बड़ी संख्या में धीमी यहीं से (अध्याय 2)।¹
• Data कई हो सकते हैं (कई data streams)। रोज़ का data «बिना नाम की stream», file.txt:नाम से extra stream। Zone.Identifier (Mark of the Web) का असली रूप (अध्याय 3)।²
• नाम भी attribute है। उसी record पर कई नाम hard links। 8.3 short name भी «एक और नाम» के रूप में साथ (अध्याय 4)।³⁴
• Reparse point «खोलें तो दूसरी जगह» का official mechanism है। Symbolic links, junctions, OneDrive Files On-Demand सब इसी tag-युक्त data के applications (अध्याय 5)।⁵⁶
• Journal दो हैं। $LogFile metadata consistency recovery के लिए (न टूटने का write-ahead log), USN Journal change history record के लिए (क्या बदला catalog)। भूमिकाएँ बिलकुल अलग (अध्याय 6)।⁷⁸
• «Size» और «size on disk» अलग वस्तुएँ हैं। Sparse file और compression अंतर पैदा करते हैं। भाग 2 का «compressed file async नहीं बनती» पृष्ठभूमि भी यहीं (अध्याय 7)।⁹¹⁰

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 35, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. सब कुछ MFT का record है

2.1. Volume का catalog

NTFS volume format करें तो MFT (master file table) और $ से शुरू metadata files की श्रृंखला बनती है। MFT में volume पर हर file के लिए कम से कम एक entry है, MFT स्वयं की entry भी शामिल।¹

flowchart TB
    subgraph VOL["NTFS volume"]
        MFT["$MFT ── Master File Table<br/>सब files के records का catalog (स्वयं भी दर्ज)"]
        LOG["$LogFile ── metadata operations का<br/>transaction log (अध्याय 6)"]
        BITMAP["$Bitmap ── cluster use स्थिति"]
        OTH["$Boot / $Secure / $UpCase आदि<br/>अन्य metadata files"]
        DATA["User data क्षेत्र<br/>(non-resident data का स्थान)"]
    end
    MFT -->|"Record स्थान इंगित करते हैं"| DATA

चित्र 1: NTFS volume की structure। «File system स्वयं की management जानकारी भी file के रूप में रखता है» NTFS का design

File की जानकारी — size, timestamp, access permissions, और data content तक — MFT entry के भीतर stored या entry स्थान वर्णित MFT-बाहर क्षेत्र में।¹ File हटाएँ तो entry «खाली» चिह्नित reuse, पर MFT स्वयं नहीं सिकुड़ता। MFT लगातार रखने को MFT Zone क्षेत्र reserved; volume भरते MFT fragmentation शुरू — यह lifetime की बात official documentation में लिखी है।¹

2.2. File = attributes का समूह, resident और non-resident

File record की content attributes की list है। Standard information (timestamp आदि), file name, security, और data। यहाँ महत्त्वपूर्ण शाखा।

flowchart TB
    subgraph REC["MFT file record (एक file का catalog)"]
        STD["Standard information attribute<br/>Timestamp · attribute flags"]
        FN["File name attribute<br/>(कई हो सकते हैं ── अध्याय 4)"]
        DATA["Data attribute"]
    end
    Q{"Data छोटा है?"}
    RES["resident<br/>Data पदार्थ record में समाता है<br/>पढ़ना MFT पहुँच मात्र से complete"]
    NONRES["non-resident<br/>Record में «cluster sequence का reference» मात्र<br/>वास्तविक data user data क्षेत्र में"]
    DATA --> Q
    Q -->|"कुछ सौ byte तक"| RES
    Q -->|"उससे अधिक"| NONRES

चित्र 2: File record attributes का समूह। Data छोटा हो तो record में «resident»

उसी record की content resident और non-resident पर कैसे बदलती है, साथ रखने से स्पष्ट।

flowchart LR
    subgraph RES2["resident ── छोटी file"]
        RA["MFT file record (स्थिर लंबाई)<br/>Standard information / file name / security<br/>─────────────<br/>Data attribute = content स्वयं<br/>«setting मान=1» यहाँ सीधे"]
        RB["Disk पर अलग स्थान नहीं<br/>पढ़ना MFT पहुँच मात्र से complete"]
        RA --> RB
    end
    subgraph NON2["non-resident ── बड़ी file"]
        NA["MFT file record (स्थिर लंबाई)<br/>Standard information / file name / security<br/>─────────────<br/>Data attribute = data run तालिका<br/>«कहाँ से कितने clusters» क्रम"]
        NB["User data क्षेत्र<br/>Run 1: लगातार clusters"]
        NC["User data क्षेत्र<br/>Run 2: दूसरे स्थान के लगातार clusters"]
        NA -->|"स्थान इंगित"| NB
        NA -->|"स्थान इंगित"| NC
    end

चित्र 3: resident और non-resident तुलना। non-resident पर record के पास «वास्तविक data कहाँ कितना» तालिका (data runs) मात्र

Data run संख्या बढ़े तो एक file पढ़ने को बिखरे क्षेत्र घूमना पड़ता है। यही आगे fragmentation का असली रूप।

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

• छोटी file दस हज़ार copy धीमी क्यों। प्रत्येक file पर MFT record बनाना, नाम registration, security setting — metadata operations। Data transfer से catalog काम प्रबल (और प्रत्येक भाग 6 के filter जाँच का लक्ष्य भी)।
• Fragmentation का असली रूप। non-resident data «cluster लगातार खंड (runs) का क्रम» दर्ज। लगातार क्षेत्र न मिले तो run संख्या बढ़े, पढ़ने को seek बढ़े — यही fragmentation। Run का वास्तविक क्रम fsutil file layout से झाँक सकते हैं।
• «Folder» विशेष नहीं। Directory «file name से MFT record संख्या का index रखने वाली file» है। Catalog पर सब एक ही mechanism पर।

3. Data «stream» में से एक मात्र है

3.1. एक file, कई byte sequences

NTFS में एक file कई data streams रख सकती है। रोज़ ReadFile/WriteFile से पढ़ा-लिखा बिना नाम की default stream है, फ़ाइलनाम:स्ट्रीमनाम वाक्यविन्यास से alternate data stream (ADS) बना सकते हैं।²

flowchart LR
    subgraph F["report.docx नाम की file (एक MFT record)"]
        D0["Default stream (अनाम)<br/>= रोज़ दिखने वाली content"]
        D1[":Zone.Identifier<br/>स्रोत जानकारी (Mark of the Web)"]
        D2[":कोई भी नाम<br/>App स्वयं की extra जानकारी"]
    end

चित्र 4: कई data streams। Explorer size display में आती केवल default stream

सबसे परिचित ADS Zone.Identifier है। Browser से download file पर इस stream में स्रोत (internet मूल आदि) दर्ज, SmartScreen का «Windows ने PC सुरक्षित किया» और Office Protected View का decision content बनता है। इस mechanism का बाहरी चेहरा «Windows पर «Windows ने PC सुरक्षित किया» क्यों आता है» में है — पीछे का असली रूप साधारण NTFS stream था।

3.2. Developer के जाल

• अदृश्य। Explorer size में भी dir list में भी नहीं। dir /r या Sysinternals streams से जाँचें।¹¹
• न ले जाई जा सके। ADS NTFS सुविधा है, FAT USB या cloud storage copy पर प्रायः जाती है। «Download warning copy करते गायब» यही।
• अपने app से भी खोल सकते हैं। CreateFile("data.txt:meta", ...) जैसे path में colon भर से पढ़-लिख सकते हैं।² सुविधाजनक, पर पिछले «न ले जाई जा सके» limitation साथ लेते हैं, इसलिए business data का मूल स्थान नहीं।

4. नाम भी attribute है — hard links और 8.3 names

4.1. Hard link — उसी record के कई नाम

चित्र 2 में «file name attribute कई हो सकते हैं» लिखा। एक ही volume में कई paths एक file reference करें — यही hard link (CreateHardLink / mklink /H)।³

flowchart TB
    subgraph DIR1["C:\\app\\ का index"]
        E1["config.json → record #1234"]
    end
    subgraph DIR2["C:\\backup\\ का index"]
        E2["config-link.json → record #1234"]
    end
    REC["MFT record #1234<br/>Data पदार्थ (या run का reference)<br/>Link count: 2"]
    E1 --> REC
    E2 --> REC

चित्र 5: Hard link। Directory index उसी MFT record इंगित करते हैं, दोनों «असली»

किसी भी नाम से बदलें वही file, content तुरंत मेल।³ और «हटाना» का अर्थ बदलता है — DeleteFile «एक नाम उतारना» है, अंतिम नाम उतरे, खुले handles बंद हों, आगे memory map section जैसे kernel references भी सब जाएँ तभी पदार्थ मिटता है। भाग 1 का cleanup (अंतिम handle) और close (अंतिम reference) दो चरण हटाने के lifetime पर भी ज्यों के त्यों लगते हैं। Attribute display की आदत: एक link से attributes बदलें तो अन्य links का दिखावट पुराना रह सकता है — official टिप्पणी।³

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

ऐतिहासिक compatibility के लिए NTFS लंबे file name पर REPORT~1.DOC जैसे 8.3 short name automatically बना सकता है। यह भी «एक और नाम» के रूप में record में साथ। बड़ी संख्या file वाले folder पर short name बनाना-टकराव टालना लागत बनता है, इसलिए fsutil 8dot3name से बनाना disable या मौजूदा short name हटाना (registry path short name से दर्ज पुराने apps टूटें तो strip से पहले जाँच सुविधा भी practical बिंदु)।⁴

ध्यान: short name है या नहीं वातावरण पर निर्भर। Default व्यवहार registry मान NtfsDisable8dot3NameCreation से तय, 0 (सब volumes पर बनाएँ), 1 (सब पर न बनाएँ), 2 (volume-दर set), 3 (system volume के अलावा न बनाएँ) चार प्रकार।⁴ 2 चुनें तो volume-दर switch, इसलिए «Windows पर PROGRA~1 जैसा short name अवश्य है» नहीं। Short name पर निर्भर code या प्रक्रिया लिखने से पहले fsutil 8dot3name query C: (volume छोड़ें तो सब volumes साझा default) से वर्तमान स्थिति जाँचें।

Path और नाम के जाल (MAX_PATH, reserved names, अंत dot) «MAX_PATH और Windows path-file name के जाल» में विस्तार से। भाग 1 का name resolution (Object Manager) और यह अध्याय (file system में नाम) मिलाकर Windows «नाम» का पूरा चित्र बनता है।

5. Reparse point — «खोलें तो दूसरी जगह» का mechanism

File या directory पर reparse point लगा सकते हैं। पदार्थ «tag + user-defined data» attribute है। File system reparse point लगी file खोले तो tag के अनुसार processing बीच में लिया जाता है — tag समझने वाला filter driver processing लेता है, या नाम बदलने वाले tag हो तो target path से resolution फिर होता है।⁵

sequenceDiagram
    participant App as App
    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: Target पर reparse point मिला<br/>Tag और data return करता है
    alt Symbolic link / junction (नाम बदलना)
        FS-->>IOM: «असली स्थान यह है»
        IOM->>FS: Target path से resolution फिर
    else Filter-managed tag (cloud file आदि)
        Note over FS: Tag समझने वाला filter<br/>processing लेता है (भाग 6)
    end

चित्र 6: Reparse point resolution। «खोलना» operation में बीच आने वाला official hook

इस एक mechanism पर परिचित सुविधाएँ पंक्ति में।

• Symbolic link (mklink) — target path रखने वाला संकेत। दूसरा volume या UNC path भी इंगित कर सकता है।⁶
• Junction / mount point — directory दूसरे local volume स्थान से जोड़ने वाला पुराना mechanism।³
• OneDrive Files On-Demand — वास्तविक data हाथ न हो file reparse point से व्यक्त, खोलते filter download कर content सौंपता है। «Explorer में दिखे, खोलें तो संचार चले» का असली रूप (filter mechanism स्वयं भाग 6 में)।

Practical सावधानी एक। «Path के आगे सच में local वह स्थान हो, ज़रूरी नहीं»। Recursive tree घूमने वाले tools junction पर loop, size सारांश दोहरा, backup cloud पदार्थ बड़ी संख्या में लाए — reparse point न जानने वाला code ये कदम रखता है। FindFirstFile परिवार का attribute FILE_ATTRIBUTE_REPARSE_POINT जाँच उपाय का द्वार है।⁵

6. दो journals — $LogFile और USN

«NTFS journaling file system» अक्सर कहा जाता है, पर NTFS में भूमिकाएँ अलग दो journals हैं। मिलाएँ तो guarantee गलत पढ़ते हैं।

flowchart TB
    subgraph J1["$LogFile ── write-ahead log (न टूटने के लिए)"]
        A1["Metadata operations (record update · rename आदि)<br/>Execution से पहले log में दर्ज"]
        A2["System failure बाद अगले startup पर<br/>Log चला structure consistency लौटाता है"]
        A1 --> A2
    end
    subgraph J2["USN Journal ── change history (क्या बदला जानने के लिए)"]
        B1["File / directory परिवर्तन हर बार<br/>Change content और नाम दर्ज"]
        B2["Backup · search index · sync tools<br/>«पिछली बार से क्या बदला» पूरा scan बिना पकड़ते हैं"]
        B1 --> B2
    end

चित्र 7: दो journals। $LogFile «न तोड़ने» के लिए, USN «परिवर्तन जानने» के लिए

अंतर तालिका में इस प्रकार।

तालिका 2: दो journals की तुलना

• $LogFile (transaction log) metadata operations का write-ahead log है। System failure हो तो NTFS अगले startup पर इस log और checkpoint जानकारी से file system consistency automatically लौटाता है।⁷ यहाँ बचती structure है। भाग 4 के अनुसार cache पर dirty data content बिजली कटने पर जा सकती है — «volume नहीं टूटता। पर अंतिम लिखना जा सकता है» सही पढ़ना।
• USN Journal (change journal) volume में file या directory बदले हर बार change content और target नाम दर्ज करता catalog है।⁸ Backup या indexer «पिछली बार से बदला मात्र» पूरा scan बिना लें, failure बाद index rebuild टालने को भी।⁸ व्यवहार में FileSystemWatcher चूक («FileSystemWatcher practical guide») पूरी करने वाला मिलान catalog fsutil usn readjournal जाँच में काम आता है, याद रखें।

7. Sparse और compression — «size» दो होने की कथा

NTFS में file की logical length और वास्तव में allocated क्षेत्र अलग managed। Properties screen के «Size» और «Size on disk»। अंतर पैदा करने वाले प्रतिनिधि दो।

Sparse file शून्य चलते दायरे को वास्तविक क्षेत्र न दे «छेद» के रूप में manage करती है।⁹ Logical size 42GB virtual disk file disk पर 500MB ही — सामान्य हो सकता है। छेद पढ़ें तो शून्य return होता है, लिखें तो उतना allocate।

flowchart LR
    subgraph L["Logical file (size: 1GB)"]
        R1["Data 10MB"]
        H1["छेद (शून्य) 500MB"]
        R2["Data 5MB"]
        H2["छेद (शून्य) शेष"]
    end
    subgraph P["Disk पर allocation (15MB + management जानकारी)"]
        A1["Run: R1 का पदार्थ"]
        A2["Run: R2 का पदार्थ"]
    end
    R1 --> A1
    R2 --> A2

चित्र 8: Sparse file। «छेद» पर allocation नहीं, logical size और size on disk अलग

NTFS compression data compression इकाई-दर compressed stored करता है।¹⁰ Transparent सुविधाजनक, पर लागत भी transparent नहीं — read-write हर बार expand-recompress, fragmentation भी बढ़ता आसान। और भाग 2 अध्याय 5 के अनुसार compressed file पहुँच async नहीं बनती (file system sync में बदलता है)। «Async I/O किया फिर भी तेज़ न हुई file» पर संदेह स्थानों में से एक।

Allocation-आधार वास्तविक size GetCompressedFileSize से मिलता है। «File size योग» और «disk usage» न मिलें जाँच में sparse, compression, ADS (अध्याय 3), cluster rounding चार क्रम से संदेह नियम है।

8. अपनी आँख से जाँचें

इस बार भी हाथ के Windows पर सब देखा जा सकता है (कुछ को admin rights)। Execution result सही स्वयं तय कर सकें, command-दर कहाँ देखें क्या पता चलता है जोड़ते हैं।

:: Alternate data streams देखें
dir /r C:\Users\%USERNAME%\Downloads

यहाँ देखें: सामान्य file पंक्ति के नीचे indent फ़ाइलनाम:Zone.Identifier:$DATA रूप की पंक्तियाँ लंबाई सहित। यह पंक्ति हो तो उस file पर Mark of the Web लगा (अध्याय 3)। Browser download file पर लगता है, स्वयं बनाई पर नहीं। दोनों स्थान चलाकर तुलना करें तो ADS होना स्पष्ट।

:: File का MFT पर layout (runs) और attributes देखें
fsutil file layout C:\path\to\file.dat

:: Extents मात्र देखें (official documentation में लिखी subcommand)
fsutil file queryextents C:\path\to\file.dat

यहाँ देखें: layout stream-दर size, allocation size, non-resident हो तो extents (VCN · LCN · cluster संख्या) list। Extent पंक्ति न हो बहुत छोटी file resident (2.2); कई पंक्तियों में बँटी हो तो fragmented। कुछ byte text file और सैकड़ों MB file चलाकर तुलना resident/non-resident सबसे छोटा अनुभव।

:: 8.3 short name बनाने की setting और मौजूदा short names
fsutil 8dot3name query C:
dir /x

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

:: USN Journal की स्थिति
fsutil usn queryjournal C:

यहाँ देखें: Journal ID, वैध USN दायरा (First USN / Next USN), target maximum size (MaximumSize) और allocation इकाई (AllocationDelta) दिखते हैं।¹² कोई file बना फिर चलाएँ तो Next USN आगे बढ़ा होना चाहिए — «परिवर्तन दर्ज हो रहा» की पुष्टि। MaximumSize अध्याय 6 «कितना पीछे» का संकेत। Journal disabled volume पर error।

:: Reparse point की जाँच (target और tag)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

यहाँ देखें: dir /aL पर आए reparse points (FILE_ATTRIBUTE_REPARSE_POINT लगा)। Symbolic link या junction <SYMLINKD> <JUNCTION> जैसे प्रकार सहित। fsutil reparsepoint query reparse tag मान और नाम बदलने वाले हो तो target path दिखाता है। Reparse point न हो target दें तो error — error स्वयं «यहाँ सामान्य folder» की पुष्टि बनती है।

Procmon से file operations पीछा करें तो इस बार के पात्र वास्तविक नाम से बहते हैं ($LogFile लिखना, stream नाम सहित path, reparse processing)। Use «Process Monitor (ProcMon) practical guide» देखें।

9. सारांश

• NTFS का केंद्र MFT। सब files catalog records, जानकारी «record में» या «record द्वारा बताए बाहरी क्षेत्र» में। छोटा data resident, बड़ा data run reference, छोटी files बड़ी संख्या में धीमी और fragmentation इसी structure के परिणाम।¹
• Data streams कई हो सकती हैं। Zone.Identifier (Mark of the Web) साधारण ADS, dir /r से दिखती है, NTFS से बाहर नहीं जाती।²¹¹
• नाम attribute है, कई हो सकते हैं। Hard link उसी record के समान स्तर नाम, 8.3 name compatibility का एक और नाम। «हटाना = नाम उतारना», पदार्थ मिटना अंतिम नाम, handle, kernel references (map section आदि) सब जाएँ तब।³⁴
• Reparse point «खोलना» का official hook, symbolic links, junctions, Files On-Demand सब applications। Tree घूमने वाला code FILE_ATTRIBUTE_REPARSE_POINT सोचे।⁵⁶
• Journal दो। $LogFile structure consistency recovery (न टूटे), USN change history (क्या बदला)। «Journaling इसलिए data भी सुरक्षित» नहीं — data durability भाग 4 के tools से बनाएँ।⁷⁸
• Logical size और allocation अलग। Sparse, compression, ADS, cluster rounding «size न मिले» के चार बड़े कारण। Compressed file async I/O न बनना सहित performance जाँच की दराज।⁹¹⁰

आगे अंतिम भाग, भाग 6 «Filter drivers और minifilters — Procmon और virus scan I/O में क्यों बीच में आ सकते हैं»। भाग 1 से बीच-बीच आए «बीच में आने वाले» — antivirus, Procmon, OneDrive, encryption — I/O में कैसे intercept करते हैं। Series समापन के रूप में device stack की दरार में खड़े निवासियों का असली रूप खोलते हैं।

संबंधित articles

• Windows I/O की गहराई (भाग 1) — सब read-write IRP बनता है: I/O system का पूरा चित्र
• Windows I/O की गहराई (भाग 2) — Sync I/O और async I/O: OVERLAPPED का असली अर्थ
• Windows I/O की गहराई (भाग 4) — Cache Manager: आपका WriteFile disk तक कब पहुँचता है
• Windows पर «Windows ने PC सुरक्षित किया» क्यों आता है
• MAX_PATH और Windows path-file name के जाल — 260 character सीमा, reserved names, अंत dot, case
• FileSystemWatcher practical guide — चूक और duplication रोक
• Network drive और UNC path के जाल — business apps में file server (shared folder) व्यवहार
• Process Monitor (ProcMon) practical guide — «setting नहीं पढ़ी», «ACCESS DENIED» दस मिनट में पकड़ना

संबंधित consulting क्षेत्र

KomuraSoft LLC file size या copy performance के अजीब व्यवहार, link-stream जुड़ी errors जैसे NTFS mechanism पर टिके Windows business apps design और जाँच सँभालता है।

• Windows app development
• Bugs की जाँच और root-cause analysis
• मौजूदा assets का reuse और migration
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

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

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

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

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

MFT (Master File Table) क्या है?

NTFS volume के हृदय की data structure, volume पर हर file के लिए कम से कम एक entry (file record) रखने वाला catalog। MFT स्वयं की entry भी शामिल। File का size, timestamp, access permissions, data content तक — file की सब जानकारी MFT entry के भीतर या entry द्वारा बताए MFT-बाहर क्षेत्र में stored। छोटी file data सहित MFT entry में समाती है (resident); बड़ी file का data स्थान (cluster sequence) reference मात्र entry में दर्ज (non-resident)। File हटाएँ तो entry खाली चिह्नित reuse, पर MFT स्वयं का size नहीं सिकुड़ता।

File पर लगा अदृश्य «Zone.Identifier» data क्या है?

NTFS की कई data streams (alternate data streams) में से एक। NTFS में एक file कई byte sequences (streams) रख सकती है; रोज़ पढ़ा-लिखा बिना नाम की default stream है। «file.txt:Zone.Identifier» जैसे colon से निर्दिष्ट extra stream में Windows file का स्रोत (internet से download आदि) दर्ज करता है। यही तथाकथित «Mark of the Web», SmartScreen warning और Office Protected View का decision content। Alternate stream Explorer size display में नहीं आती, dir /r command या Sysinternals streams tool से जाँचें। NTFS के अलावा file system (FAT आदि) पर copy करें तो नहीं बचती — यह भी ध्यान दें।

Hard link और symbolic link में क्या अंतर है?

Hard link «उसी file पदार्थ (उसी MFT record) को इंगित करने वाला समान स्तर का एक और नाम जुड़ना» है। एक ही volume में ही बनता है, किसी भी नाम से पहुँच वही file, एक नाम हटाएँ तो भी अन्य नाम बचे file नहीं मिटती। Symbolic link «दूसरे path का संकेत» है, reparse point के रूप में लागू। Target path string मात्र रखता है इसलिए दूसरा volume या remote भी इंगित कर सकता है, target जाए तो बंद गली। व्यवहार में hard link पदार्थ share (हटाने का अर्थ बदलता है), symbolic link path बदलना (relocation या redirect) — यही विभाजन मूल है।

NTFS journaling file system है, इसलिए बिजली कटने पर data नहीं जाता?

बचने का दायरा सटीक समझें। NTFS transaction log ($LogFile) file system structure (metadata) की consistency बचाता है। System failure हो तो अगले startup पर log से consistency automatically लौटा «volume टूटकर न पढ़ा जाए» रोकता है। पर लिखते बीच file data content स्वयं restore नहीं होती। Series भाग 4 के अनुसार cache पर dirty data बिजली कटने पर जाता है। यानी «volume नहीं टूटता, पर अंतिम लिखी content जा सकती है» सही समझ; data स्वयं की durability चाहिए तो FlushFileBuffers, WRITE_THROUGH, या app पक्ष लिखने का design (temporary file+rename आदि) से बनाना पड़ता है।

File का «size» और «size on disk» अलग क्यों हैं?

NTFS file की logical length और वास्तव में allocated disk क्षेत्र अलग manage करता है। सामान्य file पर भी cluster इकाई (default 4KB) पूर्णांक चढ़ा allocation से अंतर आता है, बड़ा अंतर sparse file और compressed file पर। Sparse file शून्य चलते दायरे को वास्तविक क्षेत्र न दे «छेद» के रूप में manage करती है, logical size कई GB हो disk पर कुछ MB हो सकता है। Compressed file पर compression बाद size मात्र allocated। उलटा «size on disk» बड़ा दिखे तो cluster rounding या alternate data stream कारण हो सकता है।

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

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।