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. অ্যাপ-উন্নয়ন সাড়া — প্লেসহোল্ডারকে সম্মান করুন

ডেভেলপার হিসেবে মূল নীতি প্লেসহোল্ডারকে "ভাঙা ফাইল" নয় বরং "আনয়ন খরচ আছে এমন ফাইল" ধরা।

• গণনার সময় বৈশিষ্ট্য থেকে বিচার করুন, এবং অসতর্কভাবে খুলবেন না। ফোল্ডার স্ক্যানে আগে বৈশিষ্ট্য থেকে (অধ্যায় ৪-এর বিচার) নিশ্চিত করুন শুধু-অনলাইন কি না, এবং শুধু সেই ফাইল খুলুন যার বিষয়বস্তু দরকার। "না থাকলে মারাত্মক নয়" প্রক্রিয়াকরণ — লগ সংগ্রহ, হ্যাশ গণনা, প্রিভিউ তৈরি —কে প্লেসহোল্ডার এড়ানোর বিকল্প দিন।

// .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-এ এই ফ্ল্যাগ নির্দেশ করতে পারে যে "প্রাপ্ত ডেটা দূর পক্ষে থাকবে এবং স্থানীয় স্টোরেজে ফেরত লেখা হবে না"। কিন্তু এটি শুধু প্রাপ্ত ডেটাকে স্থানীয় বাসিন্দা না করার ফ্ল্যাগ; বিষয়বস্তু পড়লে ডেটা স্থানান্তর নিজেই ঘটে। ব্যান্ডউইডথ ও বিলম্ব নিজে এড়াতে চাইলে বৈশিষ্ট্য, আকার ও টাইমস্ট্যাম্পেই শেষ করুন — পড়ার অ্যাক্সেস চাইবেন না (অ্যাক্সেস অধিকার ০ দিয়ে খুলুন, গণনার ফলের মেটাডেটা ব্যবহার করুন)। এটিই সবচেয়ে নিরাপদ।⁹

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) দিয়ে কনফিগার করতে পারেন। ডিফল্ট ০ (স্বয়ংক্রিয়ভাবে ফেরাবেন না), কিন্তু ব্যবহারকারী সেটিংস স্ক্রিন থেকে চালু করলে, বা সংস্থা কম ক্ষমতার ডিভাইসের জন্য কনফিগার করলে, "গত সপ্তাহে খোলা ফাইল মেঘ আইকনে ফিরেছে" স্বাভাবিক আচরণ হিসেবে ঘটে। পিন করা ফাইল পরিধির বাইরে, তাই "ব্যবসায়িক ফোল্ডার পিন করুন" এখানেও কাজ করে।¹²²

flowchart TB
    accTitle: Storage Sense-এর শুধু-অনলাইন স্বয়ংক্রিয় রূপান্তরের শাখা
    accDescr: Storage Sense-এর স্বয়ংক্রিয় মুক্তিতে পিন করা ফাইল পরিধির বাইরে এবং আসল বিষয়বস্তু থাকে; কয়েক দিন না খোলা আনপিন ফাইল শুধু-অনলাইনে ফেরে
    ss["Storage Sense স্বয়ংক্রিয় মুক্তি"] --> pin{"পিন?"}
    pin -->|হ্যাঁ| stay["পরিধির বাইরে; আসল বিষয়বস্তু থাকে"]
    pin -->|না| old{"কয়েক দিন খোলা হয়নি?"}
    old -->|হ্যাঁ| dehyd["শুধু-অনলাইনে ফেরানো"]
    old -->|না| keep["আসল বিষয়বস্তু থাকে"]
    ss -.-> def["ডিফল্ট ০ স্বয়ংক্রিয়ভাবে ফেরায় না"]

চিত্র 17: Storage Sense কয়েক দিন না খোলা ফাইল শুধু-অনলাইনে ফেরায়, কিন্তু পিন পরিধির বাইরে।

• ফাইল অন-ডিমান্ড নিষ্ক্রিয় করার আগে প্রভাব অনুমান করুন। FilesOnDemandEnabled নিষ্ক্রিয় করলে ক্লাসিক পূর্ণ-ডাউনলোড সিঙ্ক হয়, কিন্তু ডিস্ক খরচ ও প্রথম সিঙ্কের ব্যান্ডউইডথ ভার লাফায়। Microsoft চালু রাখার সুপারিশ করে, এবং নিষ্ক্রিয়করণকে সীমিত ব্যবস্থা ধরুন যখন নিশ্চিত যে "লক্ষ্য ব্যবহারকারীদের ডেটা আয়তন ছোট" এবং "ডিস্ক মাথা আছে"।¹¹²
• সহায়তা পদ্ধতিতে গেঁথে দিন। পরের অধ্যায়ের ট্রায়াজ পদ্ধতি "ডেস্কটপের ফাইল খোলে না" জিজ্ঞাসার টেমপ্লেটে রাখলে যিনি সামলাবেন তিনি বদলালেও সাড়ার মান থাকে।

8. ট্রায়াজ পদ্ধতি — যখন বলা হয় "ফাইল খোলে না"

পরামর্শ নিলে উপর থেকে নিচে নিশ্চিত করুন।

অন্তর্বর্তী ব্যবস্থা লক্ষ্য ফোল্ডারে ডান-ক্লিক করে "এই ডিভাইসে সবসময় রাখুন" বেছে নেওয়া (বা attrib +p /s /d)। তাতে আসল বিষয়বস্তু স্থানীয়ভাবে সাজে এবং ব্যবসা আবার চলতে পারে। তার উপর স্থায়ী সাড়া হিসেবে স্থির করুন প্রয়োজনীয় কারণ অ্যাপ পক্ষে (অধ্যায় ৬) না IT পক্ষে (অধ্যায় ৭)।

flowchart TB
    accTitle: অন্তর্বর্তী থেকে স্থায়ী সাড়ার পথ
    accDescr: অন্তর্বর্তীভাবে লক্ষ্য ফোল্ডারকে এই ডিভাইসে সবসময় রাখুন সেট করলে আসল বিষয়বস্তু স্থানীয়ভাবে সাজে যাতে ব্যবসা আবার চলে; তার উপর স্থির করেন প্রয়োজনীয় কারণ অ্যাপ পক্ষে না IT পক্ষে এবং স্থায়ী সাড়ার দিকে এগোন
    aid["অন্তর্বর্তীভাবে পিন করুন"] --> restore["আসল বিষয়বস্তু স্থানীয়ভাবে সাজে"]
    restore --> resume["ব্যবসা আবার চলে"]
    resume --> judge{"প্রয়োজনীয় কারণ কোথায়?"}
    judge -->|অ্যাপ পক্ষ| dev["অধ্যায় ৬ সাড়ার দিকে"]
    judge -->|IT পক্ষ| ops["অধ্যায় ৭ সাড়ার দিকে"]

চিত্র 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 সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।