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

“व्यावसायिक ऐप उस CSV को नहीं पढ़ पाता जो मैंने डेस्कटॉप पर सहेजी।” “पहले चलने वाला आयात PC बदलने के बाद ‘फ़ाइल नहीं मिली’ से विफल होता है।” “एक्सप्लोरर फ़ाइल दिखाता है, पर ऐप से खोलने पर त्रुटि आती है।” — पिछले कुछ वर्षों में ग्राहकों से इस तरह का परामर्श नियमित हो गया है।

जाँच करने पर कारण अक्सर ऐप बग नहीं बल्कि OneDrive का "डेस्कटॉप और दस्तावेज़ों का स्वचालित बैकअप" (Known Folder Move, KFM) और "फ़ाइलें ऑन-डिमांड" होता है। वास्तविक डेस्कटॉप C:\Users\<नाम>\OneDrive\Desktop पर चला गया है, और वहाँ दिखने वाली कुछ फ़ाइलें बिना स्थानीय सामग्री वाले "प्लेसहोल्डर" हैं। उपयोगकर्ता और IT इस बदलाव को बिना नोटिस किए PC इस्तेमाल करते रहते हैं।

अर्थात्, व्यावसायिक ऐप की निहित धारणा कि "फ़ाइल स्थानीय डिस्क पर है" बिना किसी के निर्णय के इस धारणा से बदल दी गई है कि "फ़ाइल क्लाउड में है, और स्थानीय रूप से केवल दिखावट है"। छोटे-मध्यम व्यवसायों के IT कर्मचारियों और Windows ऐप डेवलपर्स के लिए, यह लेख Microsoft Learn के प्राथमिक स्रोतों से प्लेसहोल्डर कैसे काम करते हैं, फ़ाइल गुणों से स्थिति कैसे तय करें, व्यावसायिक ऐप के विशिष्ट जाल, विकास पक्ष और IT पक्ष क्या कर सकते हैं, और जब कहा जाए "फ़ाइल नहीं खुलती" तो ट्राइएज प्रक्रिया को व्यवस्थित करता है।

flowchart TB
    accTitle: व्यावसायिक ऐप की निहित धारणा का प्रतिस्थापन
    accDescr: व्यावसायिक ऐप की निहित धारणा कि फ़ाइल स्थानीय डिस्क पर है, बिना किसी के निर्णय के इस धारणा से बदल दी गई कि वास्तविक सामग्री क्लाउड में है और स्थानीय रूप से केवल दिखावट है
    before["पारंपरिक निहित धारणा"] --> b1["स्थानीय डिस्क पर वास्तविक सामग्री"]
    after["प्रतिस्थापित धारणा"] --> a1["वास्तविक सामग्री क्लाउड में है"]
    a1 --> a2["स्थानीय रूप से केवल दिखावट है"]
    a2 -.-> note["एक प्लेसहोल्डर"]

चित्र 1: धारणा कि "वास्तविक सामग्री स्थानीय है" बिना किसी के निर्णय के "वास्तविक सामग्री क्लाउड में है; स्थानीय रूप से केवल दिखावट है" से बदल दी गई।

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

• डेस्कटॉप, दस्तावेज़ और चित्र KFM से C:\Users\<नाम>\OneDrive\ के नीचे चले गए हो सकते हैं। नया PC के प्रारंभिक सेटअप पर यह चालू होता है, और संगठन नीति से सामूहिक रूप से लागू भी कर सकता है। स्थिर पथ मानने वाला ऐप यहाँ टूटता है।¹
• वर्तमान सिंक ऐप में फ़ाइलें ऑन-डिमांड डिफ़ॉल्ट रूप से चालू हैं। दूसरे डिवाइस या वेब पर बनाई फ़ाइलें बिना स्थानीय सामग्री वाले "केवल-ऑनलाइन" प्लेसहोल्डर के रूप में दिखती हैं।²³
• प्लेसहोल्डर की वास्तविक पहचान Cloud Files API (cldflt.sys मिनीफ़िल्टर) द्वारा प्रबंधित रीपारस पॉइंट है। एक्सप्लोरर और फ़ाइल API दोनों को यह साधारण फ़ाइल लगती है, और खोलने पर स्वतः डाउनलोड (हाइड्रेशन) होता है।⁴
• स्थिति फ़ाइल गुणों से तय की जा सकती है। FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED आदि चिह्न हैं, और attrib कमांड उन्हें O, P और U अक्षरों से दिखाता है। केवल गुण जाँचने से डाउनलोड नहीं होता।⁵⁶⁷
• व्यावसायिक ऐप की विशिष्ट दुर्घटनाएँ "नहीं खुलती", "धीमी", "गुण गलत तय", "वॉच इवेंट का तूफ़ान" और "सिंक से संघर्ष" का संयोजन हैं। ऑफ़लाइन या OneDrive रुकने पर हाइड्रेशन विफल होता है, और बैच प्रक्रिया हर फ़ाइल का डाउनलोड प्रेरित करती है।⁴⁸
• ऐप-पक्ष की प्रतिक्रिया "प्लेसहोल्डर का सम्मान" है। आधार गणना के समय गुणों से निर्णय और लापरवाही से न खोलना, ज़रूरत हो तो FILE_FLAG_OPEN_NO_RECALL, और डेटा फ़ोल्डर OneDrive के नीचे न रखना है।⁹¹⁰
• IT-पक्ष की प्रतिक्रिया "पिन से संचालन" और "नीति से नियंत्रण" है। व्यावसायिक फ़ोल्डरों की वास्तविक सामग्री "इस डिवाइस पर हमेशा रखें" से सुनिश्चित करें, और Group Policy / Intune से KFM तथा फ़ाइलें ऑन-डिमांड जानबूझकर कॉन्फ़िगर करें। यह न भूलें कि Storage Sense भी "अप्रयुक्त फ़ाइलों को केवल-ऑनलाइन लौटा" सकता है।¹¹¹²

एक वाक्य में: "एक्सप्लोरर में दिखने वाली फ़ाइल" और "स्थानीय डिस्क पर वास्तविक सामग्री वाली फ़ाइल" अब एक ही चीज़ नहीं हैं।

2. क्या हो रहा है — KFM और फ़ाइलें ऑन-डिमांड

2.1. डेस्कटॉप अब C:\Users\<नाम>\Desktop नहीं रह सकता

OneDrive सिंक ऐप में Known Folder Move (KFM) नाम की सुविधा है। सेटिंग स्क्रीन पर यह "बैकअप", "महत्वपूर्ण फ़ोल्डर बैकअप करें" आदि दिखती है; चालू होने पर वास्तविक डेस्कटॉप, दस्तावेज़ और चित्र OneDrive फ़ोल्डर के नीचे स्थानांतरित (पुनर्निर्देशित) हो जाते हैं।¹

नए PC के प्रारंभिक सेटअप (OOBE) पर Microsoft खाते या कार्य खाते से साइन इन व्यापक रूप से फ़ोल्डर बैकअप को डिफ़ॉल्ट प्रस्ताव के रूप में दिखाता है, और जैसे-का-तैसा आगे बढ़ना इसे चालू कर देता है। संगठन उपयोगकर्ता से कुछ पूछे बिना सामूहिक रूप से लागू भी कर सकता है, "Windows ज्ञात फ़ोल्डरों को चुपचाप OneDrive पर ले जाएँ" नीति (KFMSilentOptIn) से।¹¹¹

flowchart TB
    accTitle: दो पथ जिनसे KFM चालू होता है
    accDescr: नए PC के प्रारंभिक सेटअप पर खाते से साइन इन फ़ोल्डर बैकअप को डिफ़ॉल्ट प्रस्ताव दिखाता है और जैसे-का-तैसा आगे बढ़ना इसे चालू करता है; संगठन में KFMSilentOptIn नीति उपयोगकर्ता से पूछे बिना सामूहिक रूप से लागू करती है
    oobe["नए PC का प्रारंभिक सेटअप"] --> signin["खाते से साइन इन"]
    signin --> prompt["बैकअप डिफ़ॉल्ट रूप से प्रस्तावित"]
    prompt --> on1["जैसे-का-तैसा आगे बढ़ना चालू करता है"]
    org["संगठन नीति"] --> silent["KFMSilentOptIn"]
    silent --> on2["बिना पूछे सामूहिक रूप से लागू"]
    on1 --> kfm["KFM चालू"]
    on2 --> kfm

चित्र 2: KFM बिना किसी के नोटिस के चालू होता है, चाहे प्रारंभिक सेटअप का डिफ़ॉल्ट प्रस्ताव हो या संगठन की मौन-लागू नीति।

असुविधा यह है कि एक्सप्लोरर में दिखावट लगभग नहीं बदलती। शेल ज्ञात-फ़ोल्डर API (SHGetKnownFolderPath और .NET का Environment.GetFolderPath) स्थानांतरण के बाद सही पथ लौटाते हैं, इसलिए सुव्यवस्थित ऐप चलता रहता है। जो टूटता है वह ऐप है जो सेटिंग फ़ाइल या कोड में C:\Users\%USERNAME%\Desktop जैसा स्थिर पथ एम्बेड करता है। PC बदलने के बाद आयात का "फ़ाइल नहीं मिली" से विफल होना इसी पैटर्न का है।

flowchart TB
    accTitle: KFM के बाद ऐप का पथ समाधान व्यवहार
    accDescr: KFM वास्तविक डेस्कटॉप और समान फ़ोल्डर OneDrive के नीचे ले जाने के बाद ज्ञात-फ़ोल्डर API वाला ऐप सही पथ से चलता रहता है, पर स्थिर पथ एम्बेड करने वाला ऐप फ़ाइल नहीं मिली से विफल होता है
    kfm["KFM चालू"] --> move["वास्तविक डेस्कटॉप आदि OneDrive के नीचे जाते हैं"]
    move --> how{"ऐप पथ कैसे हल करता है?"}
    how -->|ज्ञात-फ़ोल्डर API| ok["स्थानांतरण के बाद सही पथ पाता है और चलता रहता है"]
    how -->|हार्डकोड स्थिर पथ| ng["फ़ाइल नहीं मिली"]

चित्र 3: KFM के बाद ज्ञात-फ़ोल्डर API वाला ऐप चलता रहता है, पर स्थिर पथ हार्डकोड करने वाला ऐप यहाँ टूटता है।

2.2. फ़ाइलें ऑन-डिमांड — दिखती हैं, पर वास्तविक सामग्री नहीं

दूसरा सूत्र फ़ाइलें ऑन-डिमांड है। चालू वातावरण में OneDrive की हर फ़ाइल एक्सप्लोरर में दिखती है, पर फ़ाइल खुलने तक सामग्री डाउनलोड नहीं होती। वर्तमान सिंक ऐप में यह सुविधा डिफ़ॉल्ट चालू है, और Microsoft भी चालू रखने की सलाह देता है।²³

स्थिति एक्सप्लोरर के स्टेटस आइकन से बताई जा सकती है।¹³

यहाँ महत्वपूर्ण मध्य स्थिति है। एक बार खोली गई और अब स्थानीय सामग्री वाली फ़ाइल उपयोगकर्ता की "स्थान खाली करें" क्रिया या बाद में चर्चित Storage Sense से केवल-ऑनलाइन लौट सकती है। यही "पिछले महीने चलता था" जैसी कठिन-पुनरुत्पादन विफलता का एक कारण है।³¹²

stateDiagram-v2
    accTitle: फ़ाइलें ऑन-डिमांड की तीन स्थितियाँ और संक्रमण
    accDescr: केवल-ऑनलाइन फ़ाइल खुलने पर स्थानीय रूप से उपलब्ध हो जाती है, पर स्थान खाली करें या Storage Sense उसे केवल-ऑनलाइन लौटा सकते हैं, और केवल पिन की गई फ़ाइल स्वतः मुक्त होने से बाहर है
    s1: केवल-ऑनलाइन (क्लाउड चिह्न)
    s2: स्थानीय रूप से उपलब्ध
    s3: पिन (इस डिवाइस पर हमेशा रखें)
    s1 --> s2: खोलें (हाइड्रेशन)
    s2 --> s1: स्थान खाली करें
    s2 --> s1: Storage Sense
    s1 --> s3: इस डिवाइस पर हमेशा रखें
    s2 --> s3: इस डिवाइस पर हमेशा रखें
    s3 --> s2: अनपिन

चित्र 4: फ़ाइलें ऑन-डिमांड की तीन स्थितियाँ। "स्थानीय रूप से उपलब्ध" स्वतः केवल-ऑनलाइन लौट सकती है; पिन उससे बाहर है।

3. प्लेसहोल्डर की वास्तविक पहचान — Cloud Files API और रीपारस पॉइंट

फ़ाइलें ऑन-डिमांड Windows 10 संस्करण 1709 में आए OS तंत्र Cloud Files API पर बनी हैं। फ़ाइल-सिस्टम पक्ष की कार्य इकाई cldflt.sys नाम का मिनीफ़िल्टर है (सेवा नाम CldFlt, "Windows Cloud Files Filter Driver"), और OneDrive इस API का उपयोग करने वाले "सिंक प्रदाताओं" में से एक है।⁴⁷

प्लेसहोल्डर तकनीकी रूप से रीपारस पॉइंट है। फ़ाइल सिस्टम पर केवल नाम, आकार और टाइमस्टैंप जैसी मेटाडेटा (लगभग 1KB) होती है; सामग्री डेटा नहीं होता। जब ऐप फ़ाइल खोलकर पढ़ता है, मिनीफ़िल्टर अनुरोध पहचानता है, सिंक प्रदाता को डेटा स्थानांतरित करने को कहता है, डाउनलोड पूरा होने तक प्रतीक्षा करता है, फिर पढ़ना आगे बढ़ता है। इस प्राप्ति को हाइड्रेशन कहते हैं; स्थानीय सामग्री फेंककर प्लेसहोल्डर पर लौटना डीहाइड्रेशन है।⁴

sequenceDiagram
    accTitle: प्लेसहोल्डर खुलने पर हाइड्रेशन
    accDescr: जब ऐप प्लेसहोल्डर खोलकर पढ़ता है, cldflt.sys मिनीफ़िल्टर अनुरोध पहचानता है, सिंक प्रदाता को डेटा स्थानांतरित करने को कहता है, डाउनलोड पूरा होने तक प्रतीक्षा करता है, फिर पढ़ना आगे बढ़ता है
    participant app as व्यावसायिक ऐप
    participant flt as cldflt.sys मिनीफ़िल्टर
    participant sync as सिंक प्रदाता
    app->>flt: खोलने और पढ़ने का अनुरोध
    flt->>sync: डेटा स्थानांतरण का निर्देश
    sync-->>flt: डाउनलोड पूर्ण
    flt-->>app: पढ़ना आगे बढ़ता है

चित्र 5: प्लेसहोल्डर का पढ़ना मिनीफ़िल्टर के सिंक प्रदाता से डेटा मँगवाने के बाद आगे बढ़ता है।

"रीपारस पॉइंट" सुनकर मौजूदा कोड की संगतता की चिंता होती है जो "पहचानने पर रीपारस पॉइंट को विशेष व्यवहार देता है", पर संगतता के लिए Cloud Files API सिंक इंजन और %systemroot% के नीचे की प्रक्रियाओं को छोड़कर सभी से यह तथ्य छिपाती है कि यह रीपारस पॉइंट है। साधारण ऐप को यह "केवल थोड़ी धीमी खुलने वाली साधारण फ़ाइल" लगती है। वह पूर्ण पारदर्शिता, सुविधा के साथ-साथ, यही कारण भी है कि "ऐप को बिना नोटिस अपनी धारणाएँ टूटी मिलती हैं"।⁴ रीपारस पॉइंट का तंत्र स्वयं "NTFS Internals" में समझाया गया है।

flowchart TB
    accTitle: रीपारस पॉइंट छिपाना, और दिखावट का अंतर
    accDescr: प्लेसहोल्डर की वास्तविक पहचान रीपारस पॉइंट है, पर Cloud Files API इसे सिंक इंजन के अलावा प्रक्रियाओं से छिपाती है, इसलिए साधारण ऐप को यह केवल थोड़ी धीमी खुलने वाली साधारण फ़ाइल लगती है
    ph["प्लेसहोल्डर (रीपारस पॉइंट)"] --> who{"किस प्रक्रिया ने खोला?"}
    who -->|सिंक इंजन आदि| raw["रीपारस पॉइंट के रूप में दिखता है"]
    who -->|कोई अन्य ऐप| plain["साधारण फ़ाइल लगती है"]
    plain -.-> note["केवल थोड़ी धीमी खुलती लगती है"]

चित्र 6: यह रीपारस पॉइंट है यह तथ्य सिंक इंजन के अलावा सभी से छिपा है, और साधारण ऐप को यह साधारण फ़ाइल लगती है।

एक्सप्लोरर गुणों में प्लेसहोल्डर की विशेषता यह है कि "आकार" मूल आकार दिखाता है, जबकि "डिस्क पर आकार" लगभग 0 है। धारणा कि "आकार है, तो वास्तविक सामग्री होनी चाहिए" यहाँ नहीं चलती।

flowchart TB
    accTitle: गुणों में प्लेसहोल्डर कैसा दिखता है
    accDescr: एक्सप्लोरर गुणों में प्लेसहोल्डर आकार के रूप में मूल आकार दिखाता है जबकि डिस्क पर आकार लगभग 0 है, इसलिए धारणा कि आकार है अतः वास्तविक सामग्री होनी चाहिए नहीं चलती
    prop["प्लेसहोल्डर गुण"] --> size["आकार मूल आकार है"]
    prop --> disk["डिस्क पर आकार लगभग 0"]
    size -.-> trap["धारणा कि वास्तविक सामग्री होनी चाहिए"]
    disk -.-> truth["स्थानीय सामग्री नहीं है"]

चित्र 7: प्लेसहोल्डर "आकार" में मूल आकार दिखाता है जबकि "डिस्क पर आकार" लगभग 0 है।

4. फ़ाइल गुण स्थिति बताते हैं

प्लेसहोल्डर स्थिति साधारण फ़ाइल गुणों के रूप में प्रकाशित होती है। मुख्य इस प्रकार हैं।⁵

कमांड प्रॉम्प्ट का attrib इन्हें एक अक्षर से दिखा और सेट कर सकता है। O ऑफ़लाइन गुण है, P पिन, U अनपिन।⁶ OneDrive फ़ाइलें ऑन-डिमांड स्थिति से मेल Microsoft दस्तावेज़ में इस प्रकार व्यवस्थित है।⁷

एक चेतावनी। स्थिति बदलने का क्रम होता है। जब केवल-ऑनलाइन (U) फ़ाइल को "स्थानीय रूप से उपलब्ध" बनाना हो, अकेले -p चलाने से U लगा रहता है और वास्तविक सामग्री नहीं आती। Microsoft दस्तावेज़ भी पहले +p (हमेशा उपलब्ध) से वास्तविक सामग्री डाउनलोड करने फिर -p की प्रक्रिया दिखाता है।⁷ मौजूदा स्थिति को विश्वसनीय रूप से बदलने वाले स्क्रिप्ट में एक साथ विपरीत गुण साफ़ करना सुरक्षित है, जैसे attrib +p -u।

flowchart TB
    accTitle: केवल-ऑनलाइन से स्थानीय रूप से उपलब्ध पर स्विच करने का क्रम
    accDescr: केवल-ऑनलाइन फ़ाइल पर अकेले attrib -p चलाने से U गुण रहता है और वास्तविक सामग्री नहीं आती; पहले attrib +p से वास्तविक सामग्री डाउनलोड कर फिर -p की प्रक्रिया चाहिए
    u["केवल-ऑनलाइन (U)"] -->|केवल attrib -p| stay["U रहता है; वास्तविक सामग्री नहीं आती"]
    u -->|attrib +p| pin["पिन (वास्तविक सामग्री डाउनलोड)"]
    pin -->|attrib -p| local["स्थानीय रूप से उपलब्ध"]

चित्र 8: केवल-ऑनलाइन से स्विच करने के लिए पहले +p से वास्तविक सामग्री लें फिर -p का क्रम चाहिए।

PowerShell में निर्णय का उदाहरण। केवल गुण देखने से हाइड्रेशन नहीं होता, इसलिए जाँच और सामूहिक जाँच के लिए निश्चिंत होकर उपयोग करें।

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  # सारी सामग्री स्थानीय नहीं
        Pinned             = ($value -band 0x00080000) -ne 0  # इस डिवाइस पर हमेशा रखें
        Unpinned           = ($value -band 0x00100000) -ne 0  # केवल-ऑनलाइन
    }
}

# दस्तावेज़ फ़ोल्डर के नीचे CSV की सामूहिक जाँच (सामग्री डाउनलोड नहीं होती)।
# पथ ज्ञात-फ़ोल्डर API से हल करें। प्रदर्शन नाम
# "Documents" हार्डकोड करने से वास्तविक फ़ोल्डर नाम
# (Documents बनाम स्थानीयकृत नाम) और KFM कॉन्फ़िगरेशन के अनुसार अस्तित्वहीन पथ बन सकता है
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

[int] में कास्ट इसलिए है कि .NET की FileAttributes गणना RECALL_ON_DATA_ACCESS जैसे नाम परिभाषित नहीं करती। संख्यात्मक मान पर बिटवाइज़ संक्रियाएँ बिना कठिनाई निर्णय कर सकती हैं।

5. व्यावसायिक ऐप जिन जालों में पड़ता है

यह मुख्य विषय है। प्लेसहोल्डर पारदर्शिता अधिकतर सुविधाजनक है, पर व्यावसायिक ऐप के विशिष्ट प्रसंस्करण पैटर्न से मिलकर निम्नलिखित छह रूपों में सामने आती है।

5.1. खोलना स्वतः डाउनलोड शुरू करता है — ऑफ़लाइन "नहीं खुलती"

केवल-ऑनलाइन फ़ाइल खोलने से तुरंत हाइड्रेशन शुरू होता है। ऑनलाइन, छोटी फ़ाइल पर इतना तेज़ कि नोटिस नहीं होता, पर जब OneDrive रुका, साइन आउट या पॉज़ हो, नेटवर्क अस्वस्थ हो, या फ़ाइल बड़ी हो, तो यह "मौजूद पर नहीं खुलने वाली फ़ाइल" बन जाती है। त्रुटि ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, “The cloud file provider is not running”) जैसे क्लाउड-फ़ाइल परिवार कोड के रूप में लौट सकती है, या ऐप पक्ष पर टाइमआउट के रूप में देखी जा सकती है।⁸

आगे का जाल यह है कि File.Exists() के समकक्ष अस्तित्व जाँच, और गुण या आकार लेना, सफल होते हैं। स्थानीय-डिस्क अंतर्ज्ञान से न समझ आने वाला त्रुटि पैटर्न मिलता है: "अस्तित्व जाँच पास हुई, पर पढ़ना विफल"।

flowchart TB
    accTitle: केवल-ऑनलाइन फ़ाइल तक पहुँचने पर शाखाएँ
    accDescr: अस्तित्व जाँच तथा गुण और आकार लेना सफल होते हैं, पर सामग्री पढ़ना हाइड्रेशन शुरू करता है; OneDrive चल रहा हो और नेटवर्क स्वस्थ हो तो डाउनलोड के बाद पढ़ सकते हैं, अन्यथा 0x8007016A जैसी त्रुटि या टाइमआउट से विफल
    check["अस्तित्व जाँच, या गुण या आकार लेना"] --> ok1["सफल"]
    open["सामग्री पढ़ना"] --> hyd["हाइड्रेशन शुरू"]
    hyd --> cond{"OneDrive चल रहा और नेटवर्क स्वस्थ?"}
    cond -->|हाँ| read["डाउनलोड के बाद पठनीय"]
    cond -->|नहीं| err["0x8007016A जैसी त्रुटि, या टाइमआउट"]

चित्र 9: अस्तित्व जाँच सफल हो सकती है जबकि पढ़ना विफल हो। सफलता या विफलता OneDrive चलने और नेटवर्क पर निर्भर है।

5.2. बैच प्रक्रिया हर फ़ाइल का डाउनलोड प्रेरित करती है

फ़ोल्डर की हर फ़ाइल पढ़ने वाला बैच, हैश गणना, पूर्ण-पाठ खोज, या घर का बना बैकअप OneDrive के नीचे के वृक्ष पर चलाएँ तो आप जिस हर फ़ाइल को छूते हैं उसका हाइड्रेशन प्रेरित होता है। कई GB के फ़ोल्डर पर प्रक्रिया असामान्य रूप से धीमी हो जाती है, डाउनलोड डिस्क भी भरता है, और कम क्षमता वाले PC पर खाली स्थान की कमी दूसरी विफलता बुलाती है। फ़ाइलें ऑन-डिमांड से बचने वाली क्षमता एक पूर्ण स्कैन में गायब हो जाती है।

साथ ही, यदि ऐप स्पष्ट उपयोगकर्ता क्रिया के बिना हाइड्रेशन करता है, Windows टोस्ट दिखाकर उपयोगकर्ता को ब्लॉक का विकल्प दे सकता है। एक बार ब्लॉक होने पर वह ऐप उसके बाद डाउनलोड में विफल रहता है (सेटिंग्स में "स्वचालित फ़ाइल डाउनलोड" से हटा सकते हैं)। यही "आयात केवल किसी खास PC पर विफल" का एक कारण है।⁴

flowchart TB
    accTitle: बैच कैसे हर फ़ाइल का डाउनलोड प्रेरित करता है
    accDescr: OneDrive के नीचे बैच हर छुई फ़ाइल का हाइड्रेशन प्रेरित करता है, प्रसंस्करण विलंब और डिस्क दबाव लाता है, और यदि उपयोगकर्ता टोस्ट पर ब्लॉक करे तो उसके बाद डाउनलोड विफल रहते हैं
    scan["OneDrive के नीचे बैच"] --> touch["छुई हर फ़ाइल का हाइड्रेशन"]
    touch --> cost["प्रसंस्करण विलंब और डिस्क दबाव"]
    touch --> toast["टोस्ट दिख सकता है"]
    toast --> block{"क्या उपयोगकर्ता ने ब्लॉक किया?"}
    block -->|हाँ| fail["उसके बाद डाउनलोड विफल रहते हैं"]
    block -->|नहीं| cont["डाउनलोड जारी"]

चित्र 10: बैच हर फ़ाइल का हाइड्रेशन प्रेरित करता है, और टोस्ट पर ब्लॉक होने पर विफलताएँ उसके बाद जारी रहती हैं।

5.3. गुणों की अपेक्षा न करने वाले कोड का गलत व्यवहार

जो कोड FILE_ATTRIBUTE_OFFLINE या RECALL_ON_DATA_ACCESS नहीं जानता वह अप्रत्याशित जगह गलत व्यवहार करता है।

• गुण सटीक समानता से जाँचे जाते हैं (attributes == FileAttributes.Archive आदि), इसलिए प्लेसहोल्डर "अप्रत्याशित फ़ाइल" के रूप में बाहर या त्रुटि माना जाता है
• बैकअप या सिंक उपकरण का बहिष्करण निर्णय OFFLINE गुण को "पहले से टेप पर भेजा गया" समझकर छोड़ देता है (या, उलटा, हर वह फ़ाइल लाता है जिसे छोड़ना चाहिए था)
• केवल-पठन जाँच या आर्काइव-बिट संक्रिया गुण संयोजन तोड़ देती है

flowchart TB
    accTitle: गुणों की अपेक्षा न करने वाले कोड के गलत व्यवहार पैटर्न
    accDescr: प्लेसहोल्डर गुण न जानने वाला कोड सटीक-समानता जाँच से बहिष्करण या त्रुटि, OFFLINE की गलत व्याख्या से छोड़ना या पूर्ण प्राप्ति, या गुण संयोजन तोड़ने के रूप में गलत व्यवहार करता है
    code["गुणों की अपेक्षा न करने वाला कोड"] --> m1["सटीक-समानता जाँच"]
    code --> m2["OFFLINE की गलत व्याख्या"]
    code --> m3["गुण संक्रिया संयोजन तोड़ती है"]
    m1 --> r1["अप्रत्याशित के रूप में बाहर या त्रुटि"]
    m2 --> r2["छोड़ना, या पूर्ण प्राप्ति"]

चित्र 11: OFFLINE या RECALL-परिवार गुण न जानने वाला कोड बहिष्करण, गलत छोड़ने या गुण विनाश के रूप में गलत व्यवहार करता है।

मिनीफ़िल्टर डेवलपर्स के लिए Microsoft मार्गदर्शन साफ़ कहता है कि RECALL_ON_DATA_ACCESS वाली फ़ाइल पर लापरवाह पढ़ना या लिखना न करें। दस्तावेज़ कर्नेल ड्राइवरों के लिए है, पर सिद्धांत "इस गुण वाली फ़ाइल की सामग्री छूना = प्राप्ति लागत होती है" उपयोगकर्ता-मोड ऐप पर ज्यों का त्यों लागू होता है।¹⁰

5.4. FileSystemWatcher और सिंक की अंतःक्रिया

OneDrive के नीचे फ़ोल्डर को FileSystemWatcher से देखें तो न केवल उपयोगकर्ता क्रियाएँ बल्कि सिंक ऐप गतिविधि से बड़ी संख्या में इवेंट भी मिलते हैं। हर बार दूसरे डिवाइस का बदलाव सिंक होता है, और हर बार हाइड्रेशन या डीहाइड्रेशन गुण या आकार बदलता है, Changed इवेंट जल सकता है। आगे, जो डिज़ाइन वॉच-और-आयात का परिणाम उसी फ़ोल्डर में वापस लिखता है वह लिखना → अपलोड → गुण अद्यतन → दूसरा इवेंट के लूप में "परिवर्तन सूचनाओं का तूफ़ान" बन जाता है। इवेंट पतला करना और वास्तविक-सामग्री जाँच डिज़ाइन "A Practical Guide to FileSystemWatcher" में कवर है, पर OneDrive के नीचे उसकी आवश्यकता एक स्तर ऊँची है।

flowchart TB
    accTitle: देखने और वापस लिखने से परिवर्तन-सूचना लूप
    accDescr: यदि परिवर्तन इवेंट पाने वाला देखने वाला ऐप आयात परिणाम उसी फ़ोल्डर में लिखे, सिंक ऐप का अपलोड और गुण अद्यतन दूसरा इवेंट जलाते हैं, और यह लूप बन जाता है — परिवर्तन सूचनाओं का तूफ़ान
    ev["परिवर्तन इवेंट"] --> proc["देखने वाला ऐप आयात करता है"]
    proc --> write["उसी फ़ोल्डर में वापस लिखें"]
    write --> up["सिंक ऐप अपलोड करता है"]
    up --> attr["गुण या आकार अद्यतन"]
    attr --> ev
    sync["दूसरे डिवाइस से बदलाव का सिंक"] -.-> ev

चित्र 12: आयात परिणाम उसी फ़ोल्डर में लिखना उस लूप में बदल जाता है जिसमें सिंक ऐप गतिविधि दूसरा इवेंट पैदा करती है।

5.5. अनन्य लॉक के दौरान सिंक संघर्ष, और "प्रतिलिपि" फ़ाइलें

जब व्यावसायिक ऐप फ़ाइल अनन्य लॉक से खोले रखता है, सिंक ऐप उस फ़ाइल को न अपलोड कर सकता है न अद्यतन। लंबे समय लॉक पकड़े ऐप (Access .accdb, घर के बने प्रारूप की डेटा फ़ाइल, लॉग फ़ाइल आदि) को OneDrive के नीचे रखना सिंक त्रुटियों को सामान्य अवस्था बना देता है। उलटा, जब वही फ़ाइल कई PC पर संपादित हो, सिंक ऐप दोनों संस्करण रखने की कोशिश करता है और PC नाम या "— प्रतिलिपि" जैसी संघर्ष प्रतिलिपि पैदा करता है। "एक फ़ोल्डर, एक फ़ाइल" मानने वाला आयात इस डुप्लिकेट पर गलत व्यवहार करता है। लॉक डिज़ाइन के मूल "Mutual Exclusion Fundamentals for File-Based Integration" में हैं।

flowchart TB
    accTitle: अनन्य लॉक और बहु-PC संपादन से सिंक समस्याएँ
    accDescr: जब ऐप फ़ाइल अनन्य लॉक से खोले सिंक ऐप अद्यतन नहीं कर सकता और सिंक त्रुटियाँ सामान्य हो जाती हैं; कई PC पर वही फ़ाइल संपादित करने से संघर्ष प्रतिलिपि पैदा होती है और एक-फ़ोल्डर-एक-फ़ाइल धारणा गिरती है
    lock["ऐप अनन्य लॉक से खोलता है"] --> nosync["सिंक नहीं हो सकता; त्रुटियाँ सामान्य"]
    multi["वही फ़ाइल कई PC पर संपादित"] --> conflict["संघर्ष प्रतिलिपि पैदा"]
    conflict --> dup["PC नाम या प्रतिलिपि वाला डुप्लिकेट"]
    dup --> bad["एक-फ़ोल्डर-एक-फ़ाइल धारणा गिरती है"]

चित्र 13: अनन्य लॉक सिंक त्रुटियों को सामान्य बनाता है, और कई PC पर संपादन संघर्ष प्रतिलिपि से गलत व्यवहार बुलाता है।

5.6. एंटीवायरस और खोज इंडेक्सर हाइड्रेशन प्रेरित करते हैं

केवल व्यावसायिक ऐप ही फ़ाइल सामग्री नहीं पढ़ता। एंटीवायरस सॉफ़्टवेयर का पूर्ण स्कैन, और खोज इंडेक्सर, प्लेसहोल्डर की सामग्री छूने पर हाइड्रेशन भी प्रेरित करते हैं। Microsoft Defender जैसे उत्पाद ऑन-डिमांड स्कैन पर RECALL_ON_DATA_ACCESS गुण वाली फ़ाइलें छोड़ देते हैं, पर यह उत्पाद-पक्ष प्रतिक्रिया है, और यह नहीं मान सकते कि हर सुरक्षा उत्पाद वही सावधानी दिखाएगा। यदि "स्कैन समय हर रात नेटवर्क और डिस्क चरम पर" या "केवल-ऑनलाइन मानी गई फ़ाइलें सुबह तक सब भौतिक हो चुकी" जैसे लक्षण दिखें, इस पंक्ति पर संदेह करें।¹⁴

flowchart TB
    accTitle: सुरक्षा उत्पाद या खोज इंडेक्सर से प्रेरित हाइड्रेशन
    accDescr: जब पूर्ण स्कैन या खोज इंडेक्सर प्लेसहोल्डर सामग्री छूता है, RECALL गुण का सम्मान करने वाला उत्पाद छोड़ता है, न करने वाला हर फ़ाइल हाइड्रेट करता है और रात बैंडविड्थ दबाव या सुबह भौतिकीकरण लाता है
    av["पूर्ण स्कैन या खोज इंडेक्सर"] --> care{"RECALL गुण का सम्मान?"}
    care -->|सम्मान करने वाला उत्पाद| skip["प्लेसहोल्डर छोड़ता है"]
    care -->|न करने वाला उत्पाद| hyd["सामग्री छूकर हाइड्रेट करता है"]
    hyd --> sym1["रात को बैंडविड्थ और डिस्क चरम"]
    hyd --> sym2["सुबह तक फ़ाइलें सब भौतिक"]

चित्र 14: गुण का सम्मान न करने वाला स्कैन हर फ़ाइल का हाइड्रेशन प्रेरित करता है, और रात भार या सुबह भौतिकीकरण के रूप में दिखता है।

6. ऐप-विकास प्रतिक्रिया — प्लेसहोल्डर का सम्मान करें

डेवलपर के रूप में मूल नीति प्लेसहोल्डर को "टूटी फ़ाइल" नहीं बल्कि "प्राप्ति लागत वाली फ़ाइल" मानना है।

• गणना के समय गुणों से निर्णय करें, और लापरवाही से न खोलें। फ़ोल्डर स्कैन में पहले गुणों से (अध्याय 4 का निर्णय) पुष्टि करें कि केवल-ऑनलाइन है या नहीं, और केवल वे फ़ाइलें खोलें जिनकी सामग्री चाहिए। "गायब होने पर घातक नहीं" प्रसंस्करण — लॉग संग्रह, हैश गणना, पूर्वावलोकन निर्माण — को प्लेसहोल्डर छोड़ने का विकल्प दें।

// .NET में FileAttributes जो मान परिभाषित नहीं करता उन्हें संख्या के रूप में परिभाषित करें
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} केवल-ऑनलाइन है; इस बार छोड़ रहे हैं");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: गणना के समय गुणों से निर्णय फिर खोलने का पथ
    accDescr: फ़ोल्डर स्कैन में पहले गणना पर गुण पुष्टि करें; यदि प्लेसहोल्डर हो तो छोड़ें और चेतावनी लॉग छोड़ें, और आयात केवल अन्य फ़ाइलों पर चलाएँ, ताकि लापरवाह हाइड्रेशन टले
    enum["गणना पर गुण पुष्टि करें"] --> ph{"प्लेसहोल्डर?"}
    ph -->|हाँ| skip["छोड़ें और चेतावनी लॉग छोड़ें"]
    ph -->|नहीं| imp["आयात चलाएँ"]
    skip -.-> note["केवल आवश्यक सामग्री वाली फ़ाइलें खोलने की नीति"]

चित्र 15: गणना के समय गुणों से निर्णय करें और प्लेसहोल्डर बिना खोले छोड़ें, ताकि लापरवाह हाइड्रेशन टले।

• ध्यान दें कि FILE_FLAG_OPEN_NO_RECALL "डाउनलोड न करें" की गारंटी नहीं है। CreateFile पर यह फ़्लैग यह इरादा दिखा सकता है कि "प्राप्त डेटा दूर पक्ष पर रहे और स्थानीय स्टोरेज पर वापस न लिखा जाए"। पर यह फ़्लैग केवल प्राप्त डेटा को स्थानीय निवासी न बनाने के लिए है; यदि सामग्री पढ़ें तो डेटा स्थानांतरण स्वयं होता ही है। यदि बैंडविड्थ और विलंब स्वयं बचाना हो, गुण, आकार और टाइमस्टैंप पर ही समाप्त करें — पढ़ने की पहुँच न माँगें (पहुँच अधिकार 0 से खोलें, गणना परिणाम की मेटाडेटा उपयोग करें)। यही सबसे सुरक्षित है।⁹

flowchart TB
    accTitle: FILE_FLAG_OPEN_NO_RECALL का प्रभाव और सीमाएँ
    accDescr: FILE_FLAG_OPEN_NO_RECALL प्राप्त डेटा को स्थानीय निवासी न बनाने का फ़्लैग है; सामग्री पढ़ने पर डेटा स्थानांतरण स्वयं होता है, इसलिए स्थानांतरण बचाने के लिए सबसे सुरक्षित गुण जैसी मेटाडेटा पर समाप्त करना है
    flag["NO_RECALL फ़्लैग से खोलें"] --> read["सामग्री पढ़ें"]
    read --> transfer["डेटा स्थानांतरण होता है"]
    transfer --> nolocal["स्थानीय निवासी नहीं बनता"]
    meta["केवल मेटाडेटा पर समाप्त"] --> safe["कोई स्थानांतरण नहीं; सबसे सुरक्षित"]

चित्र 16: FILE_FLAG_OPEN_NO_RECALL केवल स्थानीय निवासी होने से रोकता है; स्थानांतरण स्वयं बचाना हो तो केवल मेटाडेटा पर समाप्त करें।

• त्रुटि संदेश में "यह OneDrive के नीचे है" रखें। पढ़ने की विफलता पर केवल यह पुष्टि कि लक्ष्य पथ %OneDrive% के नीचे है और उसे संदेश में शामिल करना क्षेत्र और हेल्प डेस्क का ट्राइएज समय बहुत घटाता है। 0x8007016A जैसी क्लाउड-फ़ाइल परिवार त्रुटि पहचानें तो आदर्श है उपयोगकर्ता को "कृपया OneDrive की स्थिति जाँचें" कहना।
• ऐप का डेटा फ़ोल्डर OneDrive के नीचे न रखें। KFM वातावरण में "दस्तावेज़" भी OneDrive के नीचे हैं। ऐप की सेटिंग्स, डेटाबेस और कार्य फ़ाइलें %ProgramData% या %LocalAppData% में रखें, और डेस्कटॉप या दस्तावेज़ को डिफ़ॉल्ट सहेजने का स्थान या डिफ़ॉल्ट आयात फ़ोल्डर न चुनें। क्या कहाँ रखें यह निर्णय "How to Choose Where a Windows App Stores Local Data" में संक्षेपित है।
• जब उपयोगकर्ता OneDrive के नीचे स्थान चुने तो व्यवहार तय करें। सहेजने का स्थान चुनने देने वाले ऐप के लिए विनिर्देश में पहले से डिज़ाइन निर्णय शामिल करें जैसे चुना पथ OneDrive के नीचे होने पर चेतावनी (OneDrive / OneDriveCommercial पर्यावरण चर के पथ के नीचे), या केवल लॉक फ़ाइल या DB रखने से इनकार।

7. IT-पक्ष प्रतिक्रिया — पिन और नीति से नियंत्रण

IT की स्थिति से यथार्थ संचालन "फ़ाइलें ऑन-डिमांड पूरी तरह बंद करें" नहीं बल्कि वास्तविक सामग्री केवल वहाँ सुनिश्चित करना जहाँ व्यवसाय को चाहिए है।

• व्यावसायिक ऐप जिन फ़ोल्डरों को पढ़ता है उन्हें पिन करें। एक्सप्लोरर के राइट-क्लिक मेनू से "इस डिवाइस पर हमेशा रखें" चुनें, या इमेजिंग स्क्रिप्ट से attrib +p -u <folder> /s /d चलाएँ (-u एक साथ निर्दिष्ट करें ताकि पहले से केवल-ऑनलाइन फ़ाइलों का मिश्रण विश्वसनीय रूप से पिन पर स्विच हो)। पिन की गई फ़ाइल की वास्तविक सामग्री स्थानीय रूप से सुनिश्चित है और बाद में चर्चित केवल-ऑनलाइन स्वचालित रूपांतरण से भी बाहर है।⁷²
• KFM और फ़ाइलें ऑन-डिमांड "जानबूझकर" कॉन्फ़िगर करें, "ध्यान देने पर चालू मिला" नहीं। मुख्य नीतियाँ (Group Policy / Intune) इस प्रकार हैं।¹¹¹

• जानें Storage Sense कैसे चलता है। Storage Sense में सुविधा है जो कई दिनों से न खोली गई क्लाउड फ़ाइलों को स्वतः केवल-ऑनलाइन लौटाती है, और दिनों की संख्या नीति (ConfigStorageSenseCloudContentDehydrationThreshold) से कॉन्फ़िगर कर सकते हैं। डिफ़ॉल्ट 0 है (स्वतः न लौटाएँ), पर यदि उपयोगकर्ता ने सेटिंग स्क्रीन से चालू किया हो, या संगठन ने कम क्षमता वाले डिवाइसों के लिए कॉन्फ़िगर किया हो, "पिछले सप्ताह खुली फ़ाइल क्लाउड आइकन पर लौट गई" सामान्य व्यवहार के रूप में होता है। पिन की गई फ़ाइल दायरे से बाहर है, इसलिए "व्यावसायिक फ़ोल्डर पिन करें" यहाँ भी काम करता है।¹²²

flowchart TB
    accTitle: Storage Sense के केवल-ऑनलाइन स्वचालित रूपांतरण की शाखाएँ
    accDescr: Storage Sense के स्वचालित मुक्त करने में पिन की गई फ़ाइल दायरे से बाहर है और वास्तविक सामग्री रहती है; कई दिनों से न खोली गई अनपिन फ़ाइल केवल-ऑनलाइन लौटती है
    ss["Storage Sense स्वचालित मुक्त"] --> pin{"पिन?"}
    pin -->|हाँ| stay["दायरे से बाहर; वास्तविक सामग्री रहती है"]
    pin -->|नहीं| old{"कई दिनों से नहीं खुली?"}
    old -->|हाँ| dehyd["केवल-ऑनलाइन लौटी"]
    old -->|नहीं| keep["वास्तविक सामग्री रहती है"]
    ss -.-> def["डिफ़ॉल्ट 0 स्वतः नहीं लौटाता"]

चित्र 17: Storage Sense कई दिनों से न खोली गई फ़ाइल को केवल-ऑनलाइन लौटाता है, पर पिन दायरे से बाहर है।

• फ़ाइलें ऑन-डिमांड अक्षम करने से पहले प्रभाव अनुमानित करें। FilesOnDemandEnabled अक्षम करना क्लासिक पूर्ण-डाउनलोड सिंक बन जाता है, पर डिस्क खपत और पहली सिंक का बैंडविड्थ भार उछलता है। Microsoft चालू रखने की सलाह देता है, और अक्षम करने को सीमित उपाय मानें जब पुष्टि हो जाए कि "लक्ष्य उपयोगकर्ताओं का डेटा आयतन छोटा है" और "डिस्क सिर है"।¹¹²
• समर्थन प्रक्रिया में शामिल करें। अगले अध्याय की ट्राइएज प्रक्रिया को "डेस्कटॉप की फ़ाइल नहीं खुलती" पूछताछ टेम्पलेट में रखने से संभालने वाला व्यक्ति बदलने पर भी प्रतिक्रिया की गुणवत्ता रहती है।

8. ट्राइएज प्रक्रिया — जब कहा जाए "फ़ाइल नहीं खुलती"

परामर्श लेते समय ऊपर से नीचे पुष्टि करें।

अंतरिम उपाय लक्ष्य फ़ोल्डर पर राइट-क्लिक कर "इस डिवाइस पर हमेशा रखें" चुनना है (या attrib +p /s /d)। इससे वास्तविक सामग्री स्थानीय रूप से व्यवस्थित होती है और व्यवसाय फिर चल सकता है। उसके ऊपर स्थायी प्रतिक्रिया के रूप में तय करें कि आवश्यक कारण ऐप पक्ष (अध्याय 6) है या IT पक्ष (अध्याय 7)।

flowchart TB
    accTitle: अंतरिम से स्थायी प्रतिक्रिया तक का पथ
    accDescr: अंतरिम रूप से लक्ष्य फ़ोल्डर को इस डिवाइस पर हमेशा रखें सेट करने से वास्तविक सामग्री स्थानीय व्यवस्थित होती है ताकि व्यवसाय फिर चले; उसके ऊपर तय करते हैं कि आवश्यक कारण ऐप पक्ष है या IT पक्ष और स्थायी प्रतिक्रिया की ओर बढ़ते हैं
    aid["अंतरिम रूप से पिन करें"] --> restore["वास्तविक सामग्री स्थानीय व्यवस्थित"]
    restore --> resume["व्यवसाय फिर चलता है"]
    resume --> judge{"आवश्यक कारण कहाँ है?"}
    judge -->|ऐप पक्ष| dev["अध्याय 6 प्रतिक्रिया की ओर"]
    judge -->|IT पक्ष| ops["अध्याय 7 प्रतिक्रिया की ओर"]

चित्र 18: अंतरिम उपाय पिन करना, वास्तविक सामग्री व्यवस्थित करना और व्यवसाय फिर चलाना है; स्थायी प्रतिक्रिया ऐप पक्ष या IT पक्ष तय करने के बाद आगे बढ़ती है।

यदि यहाँ तक पुष्टि कर ली और "पथ OneDrive के नीचे नहीं" तथा "प्लेसहोल्डर भी नहीं", तो साझा फ़ोल्डर या पथ लंबाई जैसे अन्य नियमित कारणों पर जाएँ। "Pitfalls of Network Drives and UNC Paths" और "MAX_PATH and Windows Path/Filename Pitfalls" आगे का नक्शा हैं।

9. सारांश

• KFM ने वास्तविक डेस्कटॉप, दस्तावेज़ और चित्र C:\Users\<नाम>\OneDrive\ के नीचे ले जाए हो सकते हैं। स्थिर पथ मानने वाला ऐप यहाँ टूटता है। ज्ञात-फ़ोल्डर API से हल करना पहला कदम है।
• फ़ाइलें ऑन-डिमांड डिफ़ॉल्ट चालू हैं, और बिना स्थानीय सामग्री वाले प्लेसहोल्डर स्वाभाविक रूप से मौजूद हैं। प्लेसहोल्डर Cloud Files API (cldflt.sys) रीपारस पॉइंट है, और खोलने पर स्वतः हाइड्रेट होता है।
• स्थिति फ़ाइल गुणों (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED) से तय होती है और attrib में O, P और U के रूप में दिखती है। केवल गुण जाँचने से डाउनलोड नहीं होता।
• व्यावसायिक-ऐप दुर्घटनाएँ ऑफ़लाइन हाइड्रेशन विफलता, बैच से पूर्ण डाउनलोड, गुणों की अपेक्षा न करने वाला कोड, FileSystemWatcher और सिंक की अंतःक्रिया, अनन्य लॉक और सिंक का संघर्ष, तथा सुरक्षा उत्पाद से प्रेरित हाइड्रेशन के रूप में दिखती हैं।
• ऐप पक्ष पर आधार "गुणों से निर्णय करें और लापरवाही से न खोलें", "डेटा फ़ोल्डर OneDrive के नीचे न रखें", और "त्रुटि पर कहें कि यह OneDrive के नीचे है" हैं।
• IT पक्ष पर "व्यावसायिक फ़ोल्डर पिन करना" और "KFM, फ़ाइलें ऑन-डिमांड तथा Storage Sense का नीति नियंत्रण" से इच्छित स्थिति बनाते हैं।
• ट्राइएज पथ → attrib → OneDrive चल रहा → नेटवर्क → खाली स्थान → रिकॉर्ड के क्रम में यंत्रवत चल सकता है।

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

क्या वह फ़ाइल सचमुच स्थानीय डिस्क पर है? या वहाँ केवल क्लाउड की दिखावट बैठी है?

संबंधित लेख

• 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 और क्लाउड स्टोरेज से जुड़ी व्यावसायिक-ऐप विफलताओं की जाँच संभालती है — "पहले चलने वाला आयात PC बदलने के बाद नहीं चलता", "फ़ाइल केवल किसी खास PC पर नहीं खुलती" — प्लेसहोल्डर मानने वाले फ़ाइल प्रसंस्करण और वॉच प्रसंस्करण का डिज़ाइन तथा सुधार, और KFM / फ़ाइलें ऑन-डिमांड वातावरण में सहेजने के स्थान डिज़ाइन की समीक्षाएँ। लक्षण अलग करने से शुरू करना ठीक है — कृपया संपर्क करें।

• Windows ऐप विकास
• बग और कारणों की जाँच
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

एक व्यावसायिक ऐप कहता है "फ़ाइल नहीं मिली" और डेस्कटॉप पर रखी CSV नहीं पढ़ पाता। क्यों?

कई मामलों में डेस्कटॉप फ़ोल्डर स्वयं OneDrive के Known Folder Move (KFM) से C:\Users\<उपयोगकर्ता नाम>\OneDrive\Desktop के नीचे चला गया है, या फ़ाइल केवल-ऑनलाइन प्लेसहोल्डर बन गई है। जो ऐप C:\Users\<उपयोगकर्ता नाम>\Desktop जैसा स्थिर पथ मानता है वह स्थानांतरण के बाद फ़ाइल नहीं पाता। पथ सही होने पर भी, OneDrive रुकने या नेटवर्क अस्वस्थ होने पर केवल-ऑनलाइन फ़ाइल खुलने में विफल हो सकती है। पहले पुष्टि करें कि लक्ष्य पथ OneDrive के नीचे है या नहीं, और attrib कमांड से देखें कि U (केवल-ऑनलाइन) लगा है या नहीं। अंतरिम उपाय के रूप में राइट-क्लिक मेनू पर "इस डिवाइस पर हमेशा रखें" से वास्तविक सामग्री स्थानीय रूप से सुरक्षित कर सकते हैं।

क्या कोई प्रोग्राम बता सकता है कि फ़ाइल केवल-ऑनलाइन है?

हाँ। केवल-ऑनलाइन प्लेसहोल्डर FILE_ATTRIBUTE_OFFLINE और FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000) जैसे गुण रखता है, इसलिए सामग्री डाउनलोड किए बिना फ़ाइल गुणों से स्थिति तय कर सकते हैं। गुण लेना या फ़ोल्डर की गणना हाइड्रेशन (डाउनलोड) नहीं करती। .NET में कुछ मान FileAttributes पर परिभाषित नहीं हैं, इसलिए पूर्णांक में कास्ट करके बिटवाइज़ संक्रियाओं से जाँचें। यदि सचमुच सामग्री पढ़े बिना खोलना हो, तो CreateFile का FILE_FLAG_OPEN_NO_RECALL भी उपलब्ध है।

फ़ाइलें ऑन-डिमांड बंद करने से समस्या हल हो जाती है?

इसे अंतिम उपाय मानें। बंद करने से सिंक दायरे की हर फ़ाइल स्थानीय रूप से डाउनलोड होती है, इसलिए डिस्क क्षमता और पहली सिंक का नेटवर्क भार बड़ा हो जाता है, और Microsoft भी इसे चालू रखने की सलाह देता है। व्यवहार में अधिक लचीला यही है कि व्यावसायिक ऐप जिन फ़ोल्डरों को पढ़ता है उन्हें ही "इस डिवाइस पर हमेशा रखें" (पिन) करें। अधिक मौलिक रूप से विश्वसनीय सुधार यह है कि ऐप का डेटा फ़ोल्डर और आयात फ़ोल्डर OneDrive के प्रबंधन के नीचे न हों।

मैंने "इस डिवाइस पर हमेशा रखें" सेट किया, फिर भी कुछ फ़ाइलें अंत में क्लाउड आइकन पर लौट जाती हैं। क्यों?

पहले attrib कमांड से पुष्टि करें कि फ़ाइल में सचमुच पिन (P गुण) है। पिन की गई फ़ाइल Storage Sense के केवल-ऑनलाइन स्वचालित रूपांतरण से बाहर है, लेकिन जो फ़ाइल केवल इसलिए "स्थानीय रूप से उपलब्ध" है कि किसी ने उसे खोला, बिना पिन के, Storage Sense सेटिंग्स और नीति के अनुसार कुछ समय बाद केवल-ऑनलाइन लौट सकती है। उपयोगकर्ता की अपनी "स्थान खाली करें" क्रिया, और टीम-साइट फ़ाइलों को केवल-ऑनलाइन बनाने वाली नीति (DehydrateSyncedTeamSites), भी क्लाउड आइकन लौटाती हैं। व्यवसाय के लिए स्थानीय रहने वाले फ़ोल्डरों पर फ़ोल्डर-दायरे में पिन करके चलाएँ।

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

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

Go Komura

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

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