OneDrive Files On-Demand और business apps — placeholder जो assumptions तोड़ते हैं, और उनसे कैसे निपटें

“Business app उस CSV को नहीं पढ़ पाता जो मैंने desktop पर save की।” “पहले चलने वाला import PC बदलने के बाद ‘file not found’ से fail होता है।” “Explorer file दिखाता है, पर app से खोलने पर error आता है।” — पिछले कुछ वर्षों में customers से इस तरह का परामर्श regular हो गया है।

जाँच करने पर वजह अक्सर app bug नहीं बल्कि OneDrive का "Desktop और Documents का automatic backup" (Known Folder Move, KFM) और Files On-Demand होता है। Actual Desktop C:\Users\<name>\OneDrive\Desktop पर चला गया है, और वहाँ दिखने वाली कुछ files बिना local content वाले "placeholder" हैं। User और IT इस बदलाव को बिना notice किए PC इस्तेमाल करते रहते हैं।

यानी, business app की implicit assumption कि "file local disk पर है" बिना किसी के decision के इस assumption से बदल दी गई है कि "file cloud में है, और locally सिर्फ़ दिखावट है"। SMEs के IT staff और Windows app developers के लिए, यह लेख Microsoft Learn के primary sources से placeholder कैसे काम करते हैं, file attributes से status कैसे तय करें, business app के typical जाल, development side और IT side क्या कर सकते हैं, और जब कहा जाए "file नहीं खुलती" तो triage process को व्यवस्थित करता है।

flowchart TB
    accTitle: Business app की implicit assumption का replacement
    accDescr: Business app की implicit assumption कि file local disk पर है, बिना किसी के decision के इस assumption से बदल दी गई कि actual content cloud में है और locally सिर्फ़ दिखावट है
    before["पुरानी implicit assumption"] --> b1["Local disk पर actual content"]
    after["Replace हो चुकी assumption"] --> a1["Actual content cloud में है"]
    a1 --> a2["Locally सिर्फ़ दिखावट है"]
    a2 -.-> note["एक placeholder"]

चित्र 1: Assumption कि "actual content local है" बिना किसी के decision के "actual content cloud में है; locally सिर्फ़ दिखावट है" से बदल दी गई।

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

• Desktop, Documents और Pictures KFM से C:\Users\<name>\OneDrive\ के नीचे चले गए हो सकते हैं। नया PC के initial setup पर यह चालू होता है, और organization policy से bulk में apply भी कर सकता है। Fixed path मानने वाला app यहाँ टूटता है।¹
• Current sync app में Files On-Demand default रूप से चालू हैं। दूसरे device या web पर बनाई files बिना local content वाले "online-only" placeholder के रूप में दिखती हैं।²³
• Placeholder की actual पहचान Cloud Files API (cldflt.sys minifilter) द्वारा managed reparse point है। Explorer और file API दोनों को यह ordinary file लगती है, और खोलने पर automatic download (hydration) होता है।⁴
• Status file attributes से तय की जा सकती है। FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED आदि flags हैं, और attrib command उन्हें O, P और U letters से दिखाता है। सिर्फ़ attributes check करने से download नहीं होता।⁵⁶⁷
• Business app की typical accidents "नहीं खुलती", "slow", "attributes गलत तय", "watch events का तूफ़ान" और "sync से conflict" का combination हैं। Offline या OneDrive रुकने पर hydration fail होता है, और batch process हर file का download trigger करता है।⁴⁸
• App-side response "placeholder का सम्मान" है। Base enumeration के समय attributes से decision और लापरवाही से न खोलना, ज़रूरत हो तो FILE_FLAG_OPEN_NO_RECALL, और data folder OneDrive के नीचे न रखना है।⁹¹⁰
• IT-side response "pin से operations" और "policy से control" है। Business folders की actual content "Always keep on this device" से सुनिश्चित करें, और Group Policy / Intune से KFM तथा Files On-Demand जानबूझकर configure करें। यह न भूलें कि Storage Sense भी "unused files को online-only लौटा" सकता है।¹¹¹²

एक वाक्य में: "Explorer में दिखने वाली file" और "local disk पर actual content वाली file" अब एक ही चीज़ नहीं हैं।

2. क्या हो रहा है — KFM और Files On-Demand

2.1. Desktop अब C:\Users\<name>\Desktop नहीं रह सकता

OneDrive sync app में Known Folder Move (KFM) नाम की feature है। Settings screen पर यह "Backup", "Back up important folders" आदि दिखती है; चालू होने पर actual Desktop, Documents और Pictures OneDrive folder के नीचे move (redirect) हो जाते हैं।¹

नए PC के initial setup (OOBE) पर Microsoft account या work account से sign in व्यापक रूप से folder backup को default proposal के रूप में दिखाता है, और जैसे-का-तैसा आगे बढ़ना इसे चालू कर देता है। Organization user से कुछ पूछे बिना bulk में apply भी कर सकता है, "Silently move Windows known folders to OneDrive" policy (KFMSilentOptIn) से।¹¹¹

flowchart TB
    accTitle: दो paths जिनसे KFM चालू होता है
    accDescr: नए PC के initial setup पर account से sign in folder backup को default proposal दिखाता है और जैसे-का-तैसा आगे बढ़ना इसे चालू करता है; organization में KFMSilentOptIn policy user से पूछे बिना bulk में apply करती है
    oobe["नए PC का initial setup"] --> signin["Account से sign in"]
    signin --> prompt["Backup default रूप से proposed"]
    prompt --> on1["जैसे-का-तैसा आगे बढ़ना चालू करता है"]
    org["Organization policy"] --> silent["KFMSilentOptIn"]
    silent --> on2["बिना पूछे bulk में apply"]
    on1 --> kfm["KFM चालू"]
    on2 --> kfm

चित्र 2: KFM बिना किसी के notice के चालू होता है, चाहे initial setup का default proposal हो या organization की silent-apply policy।

असुविधा यह है कि Explorer में दिखावट लगभग नहीं बदलती। Shell known-folder API (SHGetKnownFolderPath और .NET का Environment.GetFolderPath) move के बाद सही path लौटाते हैं, इसलिए सुव्यवस्थित app चलता रहता है। जो टूटता है वह app है जो settings file या code में C:\Users\%USERNAME%\Desktop जैसा fixed path embed करता है। PC बदलने के बाद import का "file not found" से fail होना इसी pattern का है।

flowchart TB
    accTitle: KFM के बाद app का path resolution व्यवहार
    accDescr: KFM actual Desktop और समान folders OneDrive के नीचे ले जाने के बाद known-folder API वाला app सही path से चलता रहता है, पर fixed path embed करने वाला app file not found से fail होता है
    kfm["KFM चालू"] --> move["Actual Desktop आदि OneDrive के नीचे जाते हैं"]
    move --> how{"App path कैसे resolve करता है?"}
    how -->|Known-folder API| ok["Move के बाद सही path पाता है और चलता रहता है"]
    how -->|Hardcoded fixed path| ng["File not found"]

चित्र 3: KFM के बाद known-folder API वाला app चलता रहता है, पर fixed path hardcode करने वाला app यहाँ टूटता है।

2.2. Files On-Demand — दिखती हैं, पर actual content नहीं

दूसरा सूत्र Files On-Demand है। चालू environment में OneDrive की हर file Explorer में दिखती है, पर file खुलने तक content download नहीं होती। Current sync app में यह feature default चालू है, और Microsoft भी चालू रखने की सलाह देता है।²³

Status Explorer के status icon से बताई जा सकती है।¹³

यहाँ महत्वपूर्ण मध्य status है। एक बार खोली गई और अब local content वाली file user की "Free up space" action या बाद में चर्चित Storage Sense से online-only लौट सकती है। यही "पिछले महीने चलता था" जैसी कठिन-reproduce failure का एक कारण है।³¹²

stateDiagram-v2
    accTitle: Files On-Demand की तीन statuses और transition
    accDescr: Online-only file खुलने पर locally available हो जाती है, पर Free up space या Storage Sense उसे online-only लौटा सकते हैं, और सिर्फ़ pinned file automatic free होने से बाहर है
    s1: Online-only (cloud icon)
    s2: Locally available
    s3: Pin (Always keep on this device)
    s1 --> s2: खोलें (hydration)
    s2 --> s1: Free up space
    s2 --> s1: Storage Sense
    s1 --> s3: Always keep on this device
    s2 --> s3: Always keep on this device
    s3 --> s2: Unpin

चित्र 4: Files On-Demand की तीन statuses। "Locally available" automatic online-only लौट सकती है; pin उससे बाहर है।

3. Placeholder की actual पहचान — Cloud Files API और reparse point

Files On-Demand Windows 10 version 1709 में आए OS mechanism Cloud Files API पर बनी हैं। File-system side की working unit cldflt.sys नाम का minifilter है (service name CldFlt, "Windows Cloud Files Filter Driver"), और OneDrive इस API का उपयोग करने वाले "sync providers" में से एक है।⁴⁷

Placeholder technically reparse point है। File system पर सिर्फ़ name, size और timestamp जैसी metadata (लगभग 1KB) होती है; content data नहीं होता। जब app file खोलकर पढ़ता है, minifilter request पहचानता है, sync provider को data transfer करने को कहता है, download पूरा होने तक wait करता है, फिर read आगे बढ़ता है। इस प्राप्ति को hydration कहते हैं; local content फेंककर placeholder पर लौटना dehydration है।⁴

sequenceDiagram
    accTitle: Placeholder खुलने पर hydration
    accDescr: जब app placeholder खोलकर पढ़ता है, cldflt.sys minifilter request पहचानता है, sync provider को data transfer करने को कहता है, download पूरा होने तक wait करता है, फिर read आगे बढ़ता है
    participant app as Business app
    participant flt as cldflt.sys minifilter
    participant sync as Sync provider
    app->>flt: Open और read का request
    flt->>sync: Data transfer का निर्देश
    sync-->>flt: Download complete
    flt-->>app: Read आगे बढ़ता है

चित्र 5: Placeholder का read minifilter के sync provider से data मँगवाने के बाद आगे बढ़ता है।

"Reparse point" सुनकर existing code की compatibility की चिंता होती है जो "पहचानने पर reparse point को special behavior देता है", पर compatibility के लिए Cloud Files API sync engine और %systemroot% के नीचे की processes को छोड़कर सभी से यह तथ्य छिपाती है कि यह reparse point है। Ordinary app को यह "सिर्फ़ थोड़ी slow खुलने वाली ordinary file" लगती है। वह पूर्ण transparency, feature के साथ-साथ, यही कारण भी है कि "app को बिना notice अपनी assumptions टूटी मिलती हैं"।⁴ Reparse point का mechanism स्वयं "NTFS Internals" में समझाया गया है।

flowchart TB
    accTitle: Reparse point छिपाना, और दिखावट का अंतर
    accDescr: Placeholder की actual पहचान reparse point है, पर Cloud Files API इसे sync engine के अलावा processes से छिपाती है, इसलिए ordinary app को यह सिर्फ़ थोड़ी slow खुलने वाली ordinary file लगती है
    ph["Placeholder (reparse point)"] --> who{"किस process ने खोला?"}
    who -->|Sync engine आदि| raw["Reparse point के रूप में दिखता है"]
    who -->|कोई अन्य app| plain["Ordinary file लगती है"]
    plain -.-> note["सिर्फ़ थोड़ी slow खुलती लगती है"]

चित्र 6: यह reparse point है यह तथ्य sync engine के अलावा सभी से छिपा है, और ordinary app को यह ordinary file लगती है।

Explorer properties में placeholder की विशेषता यह है कि "Size" original size दिखाता है, जबकि "Size on disk" लगभग 0 है। Assumption कि "size है, तो actual content होनी चाहिए" यहाँ नहीं चलती।

flowchart TB
    accTitle: Properties में placeholder कैसा दिखता है
    accDescr: Explorer properties में placeholder Size के रूप में original size दिखाता है जबकि Size on disk लगभग 0 है, इसलिए assumption कि size है अतः actual content होनी चाहिए नहीं चलती
    prop["Placeholder properties"] --> size["Size original size है"]
    prop --> disk["Size on disk लगभग 0"]
    size -.-> trap["Assumption कि actual content होनी चाहिए"]
    disk -.-> truth["Local content नहीं है"]

चित्र 7: Placeholder "Size" में original size दिखाता है जबकि "Size on disk" लगभग 0 है।

4. File attributes status बताते हैं

Placeholder status ordinary file attributes के रूप में published होती है। मुख्य इस प्रकार हैं।⁵

Command Prompt का attrib इन्हें एक letter से दिखा और set कर सकता है। O offline attribute है, P pin, U unpin।⁶ OneDrive Files On-Demand status से match Microsoft documentation में इस प्रकार व्यवस्थित है।⁷

एक चेतावनी। Status बदलने का क्रम होता है। जब online-only (U) file को "locally available" बनाना हो, अकेले -p चलाने से U लगा रहता है और actual content नहीं आती। Microsoft documentation भी पहले +p (always available) से actual content download करने फिर -p की process दिखाता है।⁷ Existing status को reliably बदलने वाले scripts में एक साथ विपरीत attributes साफ़ करना सुरक्षित है, जैसे attrib +p -u।

flowchart TB
    accTitle: Online-only से locally available पर switch करने का क्रम
    accDescr: Online-only file पर अकेले attrib -p चलाने से U attribute रहता है और actual content नहीं आती; पहले attrib +p से actual content download कर फिर -p की process चाहिए
    u["Online-only (U)"] -->|केवल attrib -p| stay["U रहता है; actual content नहीं आती"]
    u -->|attrib +p| pin["Pin (actual content download)"]
    pin -->|attrib -p| local["Locally available"]

चित्र 8: Online-only से switch करने के लिए पहले +p से actual content लें फिर -p का क्रम चाहिए।

PowerShell में decision का उदाहरण। सिर्फ़ attributes देखने से hydration नहीं होता, इसलिए जाँच और bulk check के लिए निश्चिंत होकर उपयोग करें।

function Test-CloudPlaceholder {
    param([Parameter(Mandatory)][string]$Path)

    $value = [int](Get-Item -LiteralPath $Path -Force).Attributes

    [pscustomobject]@{
        Path               = $Path
        Offline            = ($value -band 0x00001000) -ne 0  # FILE_ATTRIBUTE_OFFLINE
        RecallOnDataAccess = ($value -band 0x00400000) -ne 0  # सारी content local नहीं
        Pinned             = ($value -band 0x00080000) -ne 0  # Always keep on this device
        Unpinned           = ($value -band 0x00100000) -ne 0  # Online-only
    }
}

# Documents folder के नीचे CSV की bulk check (content download नहीं होती)।
# Path known-folder API से resolve करें। Display name
# "Documents" hardcode करने से actual folder name
# (Documents बनाम localized name) और KFM configuration के अनुसार nonexistent path बन सकता है
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

[int] में cast इसलिए है कि .NET की FileAttributes enum RECALL_ON_DATA_ACCESS जैसे names define नहीं करती। Numeric values पर bitwise operations बिना कठिनाई decision कर सकती हैं।

5. Business app जिन जालों में पड़ता है

यह मुख्य विषय है। Placeholder transparency अधिकतर सुविधाजनक है, पर business app के typical processing patterns से मिलकर निम्नलिखित छह रूपों में सामने आती है।

5.1. खोलना automatic download शुरू करता है — offline "नहीं खुलती"

Online-only file खोलने से तुरंत hydration शुरू होता है। Online, छोटी file पर इतना तेज़ कि notice नहीं होता, पर जब OneDrive रुका, sign out या pause हो, network खराब हो, या file बड़ी हो, तो यह "मौजूद पर नहीं खुलने वाली file" बन जाती है। Error ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, “The cloud file provider is not running”) जैसे cloud-file family codes के रूप में लौट सकती है, या app side पर timeout के रूप में देखी जा सकती है।⁸

आगे का जाल यह है कि File.Exists() के समकक्ष existence check, और attributes या size लेना, succeed होते हैं। Local-disk intuition से न समझ आने वाला error pattern मिलता है: "existence check pass हुई, पर read fail"।

flowchart TB
    accTitle: Online-only file तक access करने पर branches
    accDescr: Existence check तथा attributes और size लेना succeed होते हैं, पर content पढ़ना hydration शुरू करता है; OneDrive चल रहा हो और network healthy हो तो download के बाद पढ़ सकते हैं, अन्यथा 0x8007016A जैसी error या timeout से fail
    check["Existence check, या attributes या size लेना"] --> ok1["Succeed"]
    open["Content पढ़ना"] --> hyd["Hydration शुरू"]
    hyd --> cond{"OneDrive चल रहा और network healthy?"}
    cond -->|हाँ| read["Download के बाद readable"]
    cond -->|नहीं| err["0x8007016A जैसी error, या timeout"]

चित्र 9: Existence check succeed हो सकती है जबकि read fail हो। Success या failure OneDrive चलने और network पर निर्भर है।

5.2. Batch process हर file का download trigger करता है

Folder की हर file पढ़ने वाला batch, hash calculation, full-text search, या घर का बना backup OneDrive के नीचे के tree पर चलाएँ तो आप जिस हर file को छूते हैं उसका hydration trigger होता है। कई GB के folder पर process abnormally slow हो जाती है, download disk भी भरता है, और कम capacity वाले PC पर free space की कमी दूसरी failure बुलाती है। Files On-Demand से बचने वाली capacity एक full scan में गायब हो जाती है।

साथ ही, यदि app explicit user action के बिना hydration करता है, Windows toast दिखाकर user को block का option दे सकता है। एक बार block होने पर वह app उसके बाद download में fail रहता है (Settings में "Automatic file downloads" से हटा सकते हैं)। यही "import सिर्फ़ किसी खास PC पर fail" का एक कारण है।⁴

flowchart TB
    accTitle: Batch कैसे हर file का download trigger करता है
    accDescr: OneDrive के नीचे batch हर छुई file का hydration trigger करता है, processing delay और disk pressure लाता है, और यदि user toast पर block करे तो उसके बाद download fail रहते हैं
    scan["OneDrive के नीचे batch"] --> touch["छुई हर file का hydration"]
    touch --> cost["Processing delay और disk pressure"]
    touch --> toast["Toast दिख सकता है"]
    toast --> block{"क्या user ने block किया?"}
    block -->|हाँ| fail["उसके बाद download fail रहते हैं"]
    block -->|नहीं| cont["Download जारी"]

चित्र 10: Batch हर file का hydration trigger करता है, और toast पर block होने पर failures उसके बाद जारी रहती हैं।

5.3. Attributes की अपेक्षा न करने वाले code का गलत व्यवहार

जो code FILE_ATTRIBUTE_OFFLINE या RECALL_ON_DATA_ACCESS नहीं जानता वह unexpected जगह गलत व्यवहार करता है।

• Attributes exact equality से check होते हैं (attributes == FileAttributes.Archive आदि), इसलिए placeholder "unexpected file" के रूप में बाहर या error माना जाता है
• Backup या sync tool का exclusion decision OFFLINE attribute को "पहले से tape पर भेजा गया" समझकर छोड़ देता है (या, उलटा, हर वह file लाता है जिसे छोड़ना चाहिए था)
• Read-only check या archive-bit operation attribute combination तोड़ देती है

flowchart TB
    accTitle: Attributes की अपेक्षा न करने वाले code के गलत व्यवहार patterns
    accDescr: Placeholder attributes न जानने वाला code exact-equality check से exclusion या error, OFFLINE की गलत व्याख्या से छोड़ना या full recall, या attribute combination तोड़ने के रूप में गलत व्यवहार करता है
    code["Attributes की अपेक्षा न करने वाला code"] --> m1["Exact-equality check"]
    code --> m2["OFFLINE की गलत व्याख्या"]
    code --> m3["Attribute operation combination तोड़ती है"]
    m1 --> r1["Unexpected के रूप में बाहर या error"]
    m2 --> r2["छोड़ना, या full recall"]

चित्र 11: OFFLINE या RECALL-family attributes न जानने वाला code exclusion, गलत छोड़ने या attribute destruction के रूप में गलत व्यवहार करता है।

Minifilter developers के लिए Microsoft guidance साफ़ कहता है कि RECALL_ON_DATA_ACCESS वाली file पर लापरवाह read या write न करें। Documentation kernel drivers के लिए है, पर principle "इस attribute वाली file की content छूना = recall cost होती है" user-mode app पर ज्यों का त्यों लागू होता है।¹⁰

5.4. FileSystemWatcher और sync की interaction

OneDrive के नीचे folder को FileSystemWatcher से देखें तो न सिर्फ़ user actions बल्कि sync app activity से बड़ी संख्या में events भी मिलते हैं। हर बार दूसरे device का बदलाव sync होता है, और हर बार hydration या dehydration attributes या size बदलता है, Changed event जल सकता है। आगे, जो design watch-and-import का result उसी folder में वापस लिखता है वह write → upload → attribute update → दूसरा event के loop में "change notifications का तूफ़ान" बन जाता है। Event thinning और actual-content check design "A Practical Guide to FileSystemWatcher" में cover है, पर OneDrive के नीचे उसकी आवश्यकता एक स्तर ऊँची है।

flowchart TB
    accTitle: Watching और वापस लिखने से change-notification loop
    accDescr: यदि change event पाने वाला watching app import result उसी folder में लिखे, sync app का upload और attribute update दूसरा event जलाते हैं, और यह loop बन जाता है — change notifications का तूफ़ान
    ev["Change event"] --> proc["Watching app import करता है"]
    proc --> write["उसी folder में वापस लिखें"]
    write --> up["Sync app upload करता है"]
    up --> attr["Attributes या size update"]
    attr --> ev
    sync["दूसरे device से बदलाव का sync"] -.-> ev

चित्र 12: Import result उसी folder में लिखना उस loop में बदल जाता है जिसमें sync app activity दूसरा event पैदा करती है।

5.5. Exclusive lock के दौरान sync conflict, और "copy" files

जब business app file exclusive lock से खोले रखता है, sync app उस file को न upload कर सकता है न update। लंबे समय lock पकड़े apps (Access .accdb, घर के बने format की data file, log file आदि) को OneDrive के नीचे रखना sync errors को normal state बना देता है। उलटा, जब वही file कई PCs पर edit हो, sync app दोनों versions रखने की कोशिश करता है और PC name या "— copy" जैसी conflict copies पैदा करता है। "एक folder, एक file" मानने वाला import इस duplicate पर गलत व्यवहार करता है। Lock design के मूल "Mutual Exclusion Fundamentals for File-Based Integration" में हैं।

flowchart TB
    accTitle: Exclusive lock और multi-PC edit से sync problems
    accDescr: जब app file exclusive lock से खोले sync app update नहीं कर सकता और sync errors normal हो जाती हैं; कई PCs पर वही file edit करने से conflict copy पैदा होती है और एक-folder-एक-file assumption गिरती है
    lock["App exclusive lock से खोलता है"] --> nosync["Sync नहीं हो सकता; errors normal"]
    multi["वही file कई PCs पर edit"] --> conflict["Conflict copy पैदा"]
    conflict --> dup["PC name या copy वाला duplicate"]
    dup --> bad["एक-folder-एक-file assumption गिरती है"]

चित्र 13: Exclusive lock sync errors को normal बनाता है, और कई PCs पर edit conflict copy से गलत व्यवहार बुलाता है।

5.6. Antivirus और search indexer hydration trigger करते हैं

सिर्फ़ business app ही file content नहीं पढ़ता। Antivirus software का full scan, और search indexer, placeholder की content छूने पर hydration भी trigger करते हैं। Microsoft Defender जैसे products on-demand scan पर RECALL_ON_DATA_ACCESS attribute वाली files छोड़ देते हैं, पर यह product-side response है, और यह नहीं मान सकते कि हर security product वही सावधानी दिखाएगा। यदि "scan time हर रात network और disk चरम पर" या "online-only मानी गई files सुबह तक सब physical हो चुकी" जैसे लक्षण दिखें, इस पंक्ति पर संदेह करें।¹⁴

flowchart TB
    accTitle: Security product या search indexer से triggered hydration
    accDescr: जब full scan या search indexer placeholder content छूता है, RECALL attribute का सम्मान करने वाला product छोड़ता है, न करने वाला हर file hydrate करता है और रात bandwidth pressure या सुबह physicalization लाता है
    av["Full scan या search indexer"] --> care{"RECALL attribute का सम्मान?"}
    care -->|सम्मान करने वाला product| skip["Placeholder छोड़ता है"]
    care -->|न करने वाला product| hyd["Content छूकर hydrate करता है"]
    hyd --> sym1["रात को bandwidth और disk चरम"]
    hyd --> sym2["सुबह तक files सब physical"]

चित्र 14: Attribute का सम्मान न करने वाला scan हर file का hydration trigger करता है, और रात load या सुबह physicalization के रूप में दिखता है।

6. App-development response — placeholder का सम्मान करें

Developer के रूप में मूल policy placeholder को "टूटी file" नहीं बल्कि "recall cost वाली file" मानना है।

• Enumeration के समय attributes से decision करें, और लापरवाही से न खोलें। Folder scan में पहले attributes से (अध्याय 4 का decision) confirm करें कि online-only है या नहीं, और सिर्फ़ वे files खोलें जिनकी content चाहिए। "गायब होने पर घातक नहीं" processing — log collection, hash calculation, preview generation — को placeholder छोड़ने का option दें।

// .NET में FileAttributes जो मान define नहीं करता उन्हें संख्या के रूप में define करें
const FileAttributes RecallOnDataAccess = (FileAttributes)0x00400000;
const FileAttributes RecallOnOpen       = (FileAttributes)0x00040000;

static bool IsCloudPlaceholder(FileAttributes attributes) =>
    (attributes & (RecallOnDataAccess | RecallOnOpen | FileAttributes.Offline)) != 0;

foreach (var file in new DirectoryInfo(watchFolder).EnumerateFiles("*.csv"))
{
    if (IsCloudPlaceholder(file.Attributes))
    {
        log.Warn($"{file.Name} online-only है; इस बार छोड़ रहे हैं");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: Enumeration के समय attributes से decision फिर खोलने का path
    accDescr: Folder scan में पहले enumeration पर attributes confirm करें; यदि placeholder हो तो छोड़ें और warning log छोड़ें, और import सिर्फ़ अन्य files पर चलाएँ, ताकि लापरवाह hydration टले
    enum["Enumeration पर attributes confirm करें"] --> ph{"Placeholder?"}
    ph -->|हाँ| skip["छोड़ें और warning log छोड़ें"]
    ph -->|नहीं| imp["Import चलाएँ"]
    skip -.-> note["सिर्फ़ आवश्यक content वाली files खोलने की policy"]

चित्र 15: Enumeration के समय attributes से decision करें और placeholder बिना खोले छोड़ें, ताकि लापरवाह hydration टले।

• ध्यान दें कि FILE_FLAG_OPEN_NO_RECALL "download न करें" की guarantee नहीं है। CreateFile पर यह flag यह intent दिखा सकता है कि "recalled data remote side पर रहे और local storage पर वापस न लिखा जाए"। पर यह flag सिर्फ़ recalled data को local resident न बनाने के लिए है; यदि content पढ़ें तो data transfer स्वयं होता ही है। यदि bandwidth और latency स्वयं बचाना हो, attributes, size और timestamp पर ही समाप्त करें — read access न माँगें (access rights 0 से खोलें, enumeration result की metadata उपयोग करें)। यही सबसे सुरक्षित है।⁹

flowchart TB
    accTitle: FILE_FLAG_OPEN_NO_RECALL का प्रभाव और सीमाएँ
    accDescr: FILE_FLAG_OPEN_NO_RECALL recalled data को local resident न बनाने का flag है; content पढ़ने पर data transfer स्वयं होता है, इसलिए transfer बचाने के लिए सबसे सुरक्षित attributes जैसी metadata पर समाप्त करना है
    flag["NO_RECALL flag से खोलें"] --> read["Content पढ़ें"]
    read --> transfer["Data transfer होता है"]
    transfer --> nolocal["Local resident नहीं बनता"]
    meta["सिर्फ़ metadata पर समाप्त"] --> safe["कोई transfer नहीं; सबसे सुरक्षित"]

चित्र 16: FILE_FLAG_OPEN_NO_RECALL सिर्फ़ local resident होने से रोकता है; transfer स्वयं बचाना हो तो सिर्फ़ metadata पर समाप्त करें।

• Error message में "यह OneDrive के नीचे है" रखें। Read की failure पर सिर्फ़ यह confirm कि target path %OneDrive% के नीचे है और उसे message में शामिल करना field और help desk का triage time बहुत घटाता है। 0x8007016A जैसी cloud-file family error पहचानें तो ideal है user को "कृपया OneDrive की status जाँचें" कहना।
• App का data folder OneDrive के नीचे न रखें। KFM environment में "Documents" भी OneDrive के नीचे हैं। App की settings, databases और working files %ProgramData% या %LocalAppData% में रखें, और Desktop या Documents को default save location या default import folder न चुनें। क्या कहाँ रखें यह decision "How to Choose Where a Windows App Stores Local Data" में संक्षेपित है।
• जब user OneDrive के नीचे location चुने तो व्यवहार तय करें। Save location चुनने देने वाले app के लिए spec में पहले से design decision शामिल करें जैसे चुना path OneDrive के नीचे होने पर warning (OneDrive / OneDriveCommercial environment variable के path के नीचे), या सिर्फ़ lock file या DB रखने से इनकार।

7. IT-side response — pin और policy से control

IT की स्थिति से यथार्थ operations "Files On-Demand पूरी तरह बंद करें" नहीं बल्कि actual content सिर्फ़ वहाँ सुनिश्चित करना जहाँ business को चाहिए है।

• Business app जिन folders को पढ़ता है उन्हें pin करें। Explorer के right-click menu से "Always keep on this device" चुनें, या imaging script से attrib +p -u <folder> /s /d चलाएँ (-u एक साथ specify करें ताकि पहले से online-only files का मिश्रण reliably pin पर switch हो)। Pinned file की actual content locally सुनिश्चित है और बाद में चर्चित online-only automatic conversion से भी बाहर है।⁷²
• KFM और Files On-Demand "जानबूझकर" configure करें, "ध्यान देने पर चालू मिला" नहीं। मुख्य policies (Group Policy / Intune) इस प्रकार हैं।¹¹¹

• जानें Storage Sense कैसे चलता है। Storage Sense में feature है जो कई दिनों से न खोली गई cloud files को automatic online-only लौटाती है, और दिनों की संख्या policy (ConfigStorageSenseCloudContentDehydrationThreshold) से configure कर सकते हैं। Default 0 है (automatic न लौटाएँ), पर यदि user ने Settings screen से चालू किया हो, या organization ने कम capacity वाले devices के लिए configure किया हो, "पिछले सप्ताह खुली file cloud icon पर लौट गई" normal व्यवहार के रूप में होता है। Pinned file scope से बाहर है, इसलिए "business folders pin करें" यहाँ भी काम करता है।¹²²

flowchart TB
    accTitle: Storage Sense के online-only automatic conversion की branches
    accDescr: Storage Sense के automatic free करने में pinned file scope से बाहर है और actual content रहती है; कई दिनों से न खोली गई unpinned file online-only लौटती है
    ss["Storage Sense automatic free"] --> pin{"Pin?"}
    pin -->|हाँ| stay["Scope से बाहर; actual content रहती है"]
    pin -->|नहीं| old{"कई दिनों से नहीं खुली?"}
    old -->|हाँ| dehyd["Online-only लौटी"]
    old -->|नहीं| keep["Actual content रहती है"]
    ss -.-> def["Default 0 automatic नहीं लौटाता"]

चित्र 17: Storage Sense कई दिनों से न खोली गई file को online-only लौटाता है, पर pin scope से बाहर है।

• Files On-Demand disable करने से पहले प्रभाव अनुमानित करें। FilesOnDemandEnabled disable करना classic full-download sync बन जाता है, पर disk खपत और पहली sync का bandwidth load उछलता है। Microsoft चालू रखने की सलाह देता है, और disable करने को limited measure मानें जब confirm हो जाए कि "target users का data volume छोटा है" और "disk सिर है"।¹¹²
• Support process में शामिल करें। अगले अध्याय की triage process को "Desktop की file नहीं खुलती" inquiry template में रखने से संभालने वाला व्यक्ति बदलने पर भी response की quality रहती है।

8. Triage process — जब कहा जाए "file नहीं खुलती"

परामर्श लेते समय ऊपर से नीचे confirm करें।

Interim fix target folder पर right-click कर "Always keep on this device" चुनना है (या attrib +p /s /d)। इससे actual content locally व्यवस्थित होती है और business फिर चल सकता है। उसके ऊपर permanent response के रूप में तय करें कि आवश्यक कारण app side (अध्याय 6) है या IT side (अध्याय 7)।

flowchart TB
    accTitle: Interim से permanent response तक का path
    accDescr: Interim रूप से target folder को Always keep on this device set करने से actual content local व्यवस्थित होती है ताकि business फिर चले; उसके ऊपर तय करते हैं कि आवश्यक कारण app side है या IT side और permanent response की ओर बढ़ते हैं
    aid["Interim रूप से pin करें"] --> restore["Actual content local व्यवस्थित"]
    restore --> resume["Business फिर चलता है"]
    resume --> judge{"आवश्यक कारण कहाँ है?"}
    judge -->|App side| dev["अध्याय 6 response की ओर"]
    judge -->|IT side| ops["अध्याय 7 response की ओर"]

चित्र 18: Interim measure pin करना, actual content व्यवस्थित करना और business फिर चलाना है; permanent response app side या IT side तय करने के बाद आगे बढ़ती है।

यदि यहाँ तक confirm कर ली और "path OneDrive के नीचे नहीं" तथा "placeholder भी नहीं", तो shared folder या path length जैसे अन्य regular कारणों पर जाएँ। "Pitfalls of Network Drives and UNC Paths" और "MAX_PATH and Windows Path/Filename Pitfalls" आगे का नक्शा हैं।

9. सारांश

• KFM ने actual Desktop, Documents और Pictures C:\Users\<name>\OneDrive\ के नीचे ले जाए हो सकते हैं। Fixed path मानने वाला app यहाँ टूटता है। Known-folder API से resolve करना पहला कदम है।
• Files On-Demand default चालू हैं, और बिना local content वाले placeholder naturally मौजूद हैं। Placeholder Cloud Files API (cldflt.sys) reparse point है, और खोलने पर automatic hydrate होता है।
• Status file attributes (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED) से तय होती है और attrib में O, P और U के रूप में दिखती है। सिर्फ़ attributes check करने से download नहीं होता।
• Business-app accidents offline hydration failure, batch से full download, attributes की अपेक्षा न करने वाला code, FileSystemWatcher और sync की interaction, exclusive lock और sync का conflict, तथा security product से triggered hydration के रूप में दिखती हैं।
• App side पर base "attributes से decision करें और लापरवाही से न खोलें", "data folder OneDrive के नीचे न रखें", और "error पर कहें कि यह OneDrive के नीचे है" हैं।
• IT side पर "business folders pin करना" और "KFM, Files On-Demand तथा Storage Sense का policy control" से intended status बनाते हैं।
• Triage path → attrib → OneDrive चल रहा → network → free space → record के क्रम में यंत्रवत चल सकता है।

अगली बार जब कहा जाए "file है पर नहीं खुलती", पहले यह पूछें।

क्या वह file सचमुच local disk पर है? या वहाँ सिर्फ़ cloud की दिखावट बैठी है?

संबंधित लेख

• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• A Practical Guide to FileSystemWatcher - Handling Missed and Duplicate Events
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims
• How to Choose Where a Windows App Stores Local Data — A Decision Table for SQLite / JSON / Registry / Access
• MAX_PATH and Windows Path/Filename Pitfalls — the 260-Character Limit, Reserved Names, Trailing Dots, and Case Sensitivity

संबंधित परामर्श क्षेत्र

KomuraSoft LLC OneDrive और cloud storage से जुड़ी business-app failures की जाँच संभालती है — "पहले चलने वाला import PC बदलने के बाद नहीं चलता", "file सिर्फ़ किसी खास PC पर नहीं खुलती" — placeholder मानने वाले file processing और watch processing का design तथा सुधार, और KFM / Files On-Demand environment में save location design की reviews। लक्षण अलग करने से शुरू करना ठीक है — कृपया संपर्क करें।

• Windows app development
• Bug और root-cause investigation
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

एक business app कहता है "file not found" और desktop पर रखी CSV नहीं पढ़ पाता। क्यों?

कई मामलों में Desktop folder खुद OneDrive के Known Folder Move (KFM) से C:\Users\<user name>\OneDrive\Desktop के नीचे चला गया है, या file सिर्फ़ online-only placeholder बन गई है। जो app C:\Users\<user name>\Desktop जैसा fixed path मानता है वह move के बाद file नहीं पाता। Path सही होने पर भी, OneDrive रुकने या network खराब होने पर online-only file खुलने में fail हो सकती है। पहले confirm करें कि target path OneDrive के नीचे है या नहीं, और attrib command से देखें कि U (online-only) लगा है या नहीं। Interim fix के रूप में right-click menu पर "Always keep on this device" से actual content locally pin कर सकते हैं।

क्या कोई program बता सकता है कि file online-only है?

हाँ। Online-only placeholder FILE_ATTRIBUTE_OFFLINE और FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000) जैसे attributes रखता है, इसलिए content download किए बिना file attributes से status तय कर सकते हैं। Attributes लेना या folder enumerate करना hydration (download) नहीं करता। .NET में कुछ values FileAttributes पर defined नहीं हैं, इसलिए integer में cast करके bitwise operations से check करें। अगर सच में content पढ़े बिना खोलना हो, तो CreateFile का FILE_FLAG_OPEN_NO_RECALL भी available है।

Files On-Demand बंद करने से problem हल हो जाती है?

इसे last resort मानें। बंद करने से sync scope की हर file locally download होती है, इसलिए disk capacity और पहली sync का network load बड़ा हो जाता है, और Microsoft भी इसे चालू रखने की सलाह देता है। Practice में ज़्यादा लचीला यही है कि business app जिन folders को पढ़ता है उन्हें ही "Always keep on this device" (pin) करें। ज़्यादा मौलिक और reliable fix यह है कि app का data folder और import folder OneDrive के management के नीचे न हों।

मैंने "Always keep on this device" set किया, फिर भी कुछ files आखिर में cloud icon पर लौट जाती हैं। क्यों?

पहले attrib command से confirm करें कि file में सचमुच pin (P attribute) है। Pinned file Storage Sense के online-only automatic conversion से बाहर है, लेकिन जो file सिर्फ़ इसलिए "locally available" है कि किसी ने उसे खोला, बिना pin के, Storage Sense settings और policy के अनुसार कुछ समय बाद online-only लौट सकती है। User की अपनी "Free up space" action, और team-site files को online-only बनाने वाली policy (DehydrateSyncedTeamSites), भी cloud icon लौटाती हैं। Business के लिए locally रहने वाले folders पर folder-scope में pin करके चलाएँ।

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

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

Go Komura

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

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