OneDrive「ファイル オンデマンド」と業務アプリ ── プレースホルダーが壊す前提と対策

「デスクトップに保存したCSVを業務アプリが読めない」「PCを入れ替えたら、今まで動いていた取込処理が『ファイルが見つかりません』で止まる」。エクスプローラーにはファイルが見えているため、保存し直しても、アプリを再起動しても、原因がつかめないことがあります。

このとき、分けて確認したいのがファイルの場所と中身がローカルにあるかです。OneDriveの「既知のフォルダーの移動(KFM)」はデスクトップなどの場所を変え、「ファイル オンデマンド」は中身を必要になるまでクラウド側に置きます。どちらも、業務アプリが従来のローカルファイルを前提にしていると問題になります。¹²

この記事では、中小企業の情シス担当者とWindowsアプリ開発者に向けて、最初に問い合わせの切り分け手順を示します。そのあとで、プレースホルダーの仕組みと属性の読み方、業務アプリの落とし穴、開発側・情シス側の対策を整理します。

1. まず結論 ── 「場所」と「実体」を別々に確認する

エクスプローラーに見えていることは、アプリが正しいパスを参照していることも、中身をすぐ読めることも保証しません。最初に、次の2つを切り分けます。

KFMで移動したパスは、既知フォルダーAPIで取得します。ファイル オンデマンドの状態は、まず属性で調べ、中身が必要なファイルだけを開きます。ファイル オンデマンドは現在の同期アプリでは既定で有効であり、Microsoftも有効のままの運用を推奨しています。問題が起きたからといって、最初から全体を無効にする必要はありません。¹³⁴

応急処置は、業務に必要なフォルダーを「常にこのデバイス上に保持する」にして実体を確保することです。ただし、間違ったパスの修正は別に必要です。恒久対処は、アプリ側では保存先・読取処理・監視処理を見直し、情シス側ではピン留めとポリシーで必要な状態を維持することになります。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全16件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 「ファイルが読めない」相談を受けたときの切り分け

2.1. パスから順に、6項目を確認する

いきなり対象フォルダーの全ファイルを開くのではなく、パスとメタデータから調べます。存在確認と読み取りを分けて考えるための手順です。

個人用と職場用など、利用しているOneDriveに応じて OneDrive / OneDriveCommercial の環境変数も手掛かりにします。「デスクトップ」という表示名だけで判断せず、アプリが実際に参照したパスと突き合わせることが重要です。

OneDrive配下ではなく、プレースホルダーでもないなら、OneDriveだけを疑い続けず、共有フォルダーやパス長などの確認へ進みます。「ネットワークドライブとUNCパスの落とし穴」「MAX_PATHとWindowsのパス・ファイル名の落とし穴」で別系統の原因を整理しています。

2.2. 応急処置と、業務を再開できるかの確認を分ける

オンライン専用で中身を読めない場合は、対象フォルダーを右クリックして「常にこのデバイス上に保持する」を選びます。スクリプトで切り替える場合は attrib +p -u <フォルダー> /s /d のように、ピン留めと同時に非ピン留め属性を外します。⁶⁷

ここで確認したいのは、操作をしたことではなく、必要なファイルのダウンロードが完了して読めることです。ピン留めはローカルに保持する意図を示す属性であり、OneDriveの停止、ネットワーク不調、空き容量不足まで解消するものではありません。同期アプリの状態と対象ファイルの実体を確認してから、取込処理を再実行します。³⁶

復旧後は、固定パスやデータ配置が原因なら6章のアプリ側対策へ、実体保持や端末設定のばらつきが原因なら7章の情シス側対策へ進みます。ピン留めで一度動いたことと、再発しない設計になったことは別です。

3. 何が変わったのか ── KFMとプレースホルダーの仕組み

3.1. KFMはデスクトップなどの実パスを変える

KFM(Known Folder Move)は、OneDriveの設定画面で「バックアップ」「重要なフォルダーをバックアップする」などと表示される機能です。有効にすると、デスクトップ・ドキュメント・ピクチャの実体がOneDrive配下へ移動します。次はパスの例です。実際のフォルダー名や同期ルートは環境によって異なるため、この文字列をそのままコードへ埋め込まないでください。¹

新しいPCの初期セットアップ(OOBE)でMicrosoftアカウントや職場アカウントにサインインした際に、バックアップが提案され、そのまま有効になる構成があります。組織では KFMSilentOptIn ポリシーにより、ユーザーの操作なしで一斉に移動することもできます。利用者が意識して設定した場合だけを想定してはいけません。¹⁸

厄介なのは、エクスプローラーの見た目がほとんど変わらないことです。SHGetKnownFolderPath や.NETの Environment.GetFolderPath を使うアプリは、移動後のパスを取得できます。一方、C:\Users\%USERNAME%\Desktop のような固定パスを設定ファイルやコードに埋め込んだアプリは、移動前の場所を探し続けます。

つまり、KFMへの対応は、まずパス解決の問題です。移動後の正しいパスが分かったあとで、そのファイルの中身がローカルにあるかを確認します。

3.2. ファイル オンデマンドは「見えること」と「中身があること」を分ける

ファイル オンデマンドが有効な環境では、同期対象のファイルをエクスプローラーに表示しながら、中身は必要になるまでダウンロードせずに済みます。他のデバイスやWebで作られたファイルも、オンライン専用のプレースホルダーとして見えます。²⁴

状態は、エクスプローラーのアイコンで見分けられます。⁹

大切なのは、一度開いた「ローカルで利用可能」と、ピン留めした「常にこのデバイス上に保持」は違うことです。前者は、ユーザーの「空き領域を増やす」操作やストレージセンサーによって、再びオンライン専用へ戻ることがあります。「先月は読めた」は、今回も中身が残っている根拠にはなりません。²¹⁰

stateDiagram-v2
    accTitle: ファイル オンデマンドの3状態と遷移
    accDescr: オンライン専用のファイルは開くとローカルで利用可能になるが、空き領域を増やす操作やストレージセンサーで再びオンライン専用へ戻り、ピン留めしたファイルだけが自動解放の対象外になる
    s1: オンライン専用（雲マーク）
    s2: ローカルで利用可能
    s3: ピン留め（常にこのデバイス上に保持）
    s1 --> s2: 開く（ハイドレーション）
    s2 --> s1: 空き領域を増やす
    s2 --> s1: ストレージセンサー
    s1 --> s3: 常にこのデバイス上に保持
    s2 --> s3: 常にこのデバイス上に保持
    s3 --> s2: ピン留め解除

図1: 一度ダウンロードしただけのファイルは、ピン留めしたファイルと違い、自動解放の対象になり得る。

3.3. 読み取り時にCloud Files APIが中身を取り寄せる

ファイル オンデマンドは、Windows 10 バージョン1709で導入されたCloud Files APIの上に実装されています。ファイルシステム側では cldflt.sys というミニフィルター(サービス名 CldFlt、Windows Cloud Files Filter Driver)が働き、OneDriveはこのAPIを使う同期プロバイダーのひとつです。¹¹⁶

中身をまだ持たないプレースホルダーは、ファイル名・サイズ・タイムスタンプなどのメタデータだけを持つリパースポイントです。Microsoftの説明では、ファイルシステムヘッダーの保存に約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: 読み取りが進む

図2: ローカルファイルに見える読み取りの途中に、同期プロバイダーによるダウンロードが入る。

Cloud Files APIは互換性のため、同期エンジンと %systemroot% 配下のプロセス以外には、リパースポイントであることを隠します。そのため、普通のアプリからは「少し開くのが遅い普通のファイル」に見えます。リパースポイントを特別扱いするコードだけで判断しようとせず、次章の属性を確認します。¹¹ リパースポイント自体の仕組みは「NTFSの内部構造」で解説しています。

エクスプローラーのプロパティでは、「サイズ」に本来のファイルサイズが表示される一方、「ディスク上のサイズ」はほぼ0という見え方になります。ファイル名があり、サイズが取得できることと、その中身がローカルにあることは別です。

4. ファイル属性で状態を調べる

4.1. 中身の状態と、保持する意図を読み分ける

プレースホルダーの状態は、通常のファイル属性として公開されます。主な属性は次のとおりです。³

OFFLINE や RECALL_ON_DATA_ACCESS は、データがすぐに利用できるかを考える手掛かりです。一方、PINNED / UNPINNED はローカルに保持する意図を表します。PやUだけを見て、ダウンロードの完了まで判断しないようにします。また、RECALL_ON_OPEN はディレクトリ列挙の結果に現れる属性であり、すべての属性取得APIで同じように得られるものではありません。³

4.2. attribで確認・変更する際は、切り替えの順序に注意する

attrib <パス> で属性を確認できます。Oはオフライン、Pはピン留め、Uは非ピン留めを表します。MicrosoftはOneDriveの状態と設定コマンドの対応を次のように整理しています。⁷⁶

オンライン専用(U)のファイルに attrib -p だけを実行しても、Uが残り、中身は取得されません。「ローカルで利用可能」にしたい場合も、先に +p で「常に利用可能」にしてダウンロードさせ、それから -p にする順序が必要です。既存の状態を切り替えるスクリプトでは、attrib +p -u のように反対側の属性も外します。⁶

4.3. PowerShellでCSVの状態を一括確認する

ファイルの属性を見るだけなら、中身のハイドレーションを起こさずに調べられます。次の例は、既知フォルダーAPIでドキュメントのパスを取得し、CSVの属性を確認します。

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)の環境や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. 業務アプリで表面化する6つの問題

プレースホルダーは壊れたファイルではありません。ただし、「存在するファイルはすぐ読める」「ローカルの監視イベントはユーザー操作によるもの」といった前提とは相性がよくありません。

5.1. 存在確認は通っても、読み取りで失敗する

オンライン専用ファイルでも、File.Exists() に相当する存在確認や、属性・サイズの取得は成功することがあります。中身を読み始めたところでハイドレーションが必要になるため、OneDriveの停止・サインアウト・一時停止、ネットワーク不調などが読み取りの失敗として表れます。大きなファイルでは、ダウンロード待ちがアプリのタイムアウトになることもあります。

クラウドファイル系のエラーとしては、ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING に対応する 0x8007016A(「クラウド ファイル プロバイダーが実行されていません」)などがあります。「ファイルがない」にまとめず、元のエラーコードと対象パスを記録してください。⁵

5.2. 一括処理が全量ダウンロードを誘発する

フォルダー内の全ファイルを読むバッチ、ハッシュ計算、全文検索、独自バックアップをOneDrive配下に向けると、中身を読んだファイルのハイドレーションが次々に発生します。数GBのフォルダーなら、処理時間だけでなく、通信量とローカルのディスク消費も増えます。低容量のPCでは、空き容量不足による別の障害につながります。

ユーザーが明示的に開いていないファイルをアプリが取り寄せると、Windowsが通知を出し、ユーザーにブロックの選択肢を示すことがあります。そこでブロックされると、そのアプリは以後のダウンロードに失敗します。解除先は設定の「ファイルの自動ダウンロード」です。「特定のPCだけ失敗する」ときは、この状態も確認します。¹¹

5.3. 追加属性を想定しないコードが誤判定する

attributes == FileAttributes.Archive のように完全一致で判定すると、ほかの属性が加わったファイルを「想定外」として除外してしまいます。バックアップ・同期ツールが OFFLINE を「テープへ退避済み」と解釈してスキップしたり、逆に不要なファイルまで取り寄せたりするケースもあります。読み取り専用チェックやアーカイブビットの変更で、ほかの属性の組み合わせを壊さないことも必要です。

Microsoftのミニフィルター向けガイダンスには、RECALL_ON_DATA_ACCESS が付いたファイルへ不用意な読み書きを発行しないための注意があります。カーネルドライバー向けの制約とユーザーモードの実装は同一ではありませんが、中身に触れると取り寄せコストが生じる点は、業務アプリでも意識する必要があります。¹²

5.4. FileSystemWatcherが同期の活動も拾う

OneDrive配下を FileSystemWatcher で監視すると、ユーザーの操作だけでなく、他デバイスからの変更の同期、ハイドレーション・デハイドレーションによる属性やサイズの更新でもイベントが発生し得ます。

さらに、取込結果を同じフォルダーへ書き戻すと、書き込み、アップロード、属性更新、再イベントというループになります。

flowchart TB
    accTitle: 監視と書き戻しによる変更通知のループ
    accDescr: 変更イベントを受けた監視アプリが取り込み結果を同じフォルダーへ書き戻すと、同期アプリのアップロードと属性更新が再びイベントを発生させ、変更通知の嵐というループになる
    ev["変更イベント"] --> proc["監視アプリが取り込み"]
    proc --> write["同じフォルダーへ書き戻し"]
    write --> up["同期アプリがアップロード"]
    up --> attr["属性やサイズが更新される"]
    attr --> ev
    sync["他デバイスの変更の同期"] -.-> ev

図3: 取込結果を監視先へ書き戻すと、同期アプリの活動も巻き込んで通知が繰り返され得る。

イベントの間引きや実体確認が必要な理由は「FileSystemWatcher実務ガイド」で扱っています。OneDrive配下では、通知をそのまま「取込可能なファイルが1つ届いた」と解釈しない設計が、いっそう重要になります。

5.5. 排他ロックと複数PCの編集が同期と衝突する

業務アプリが排他ロックで開いている間、同期アプリはそのファイルをアップロードしたり更新したりできません。Accessの .accdb、独自形式のデータファイル、ログなどを長時間開く設計では、OneDrive配下に置くことで同期エラーが常態化します。

複数のPCで同じファイルを編集した場合には、両方の版を残すために、PC名付きのファイルや「〜のコピー」といった競合コピーが生成されることもあります。「1フォルダー1ファイル」を前提にした取込処理は、この重複で誤動作します。ロック設計は「ファイル連携の排他制御の基礎知識」も参照してください。

5.6. スキャンや検索インデクサも中身を取り寄せる

中身を読むのは業務アプリだけではありません。ウイルス対策ソフトのフルスキャンや検索インデクサも、プレースホルダーの中身へアクセスすればハイドレーションを誘発します。

Azure File Syncの計画ガイドでは、Microsoft Defenderなどがオンデマンドスキャン時に RECALL_ON_DATA_ACCESS 属性の付いたファイルをスキップすることが説明されています。ただし、これは製品側の対応であり、すべてのセキュリティ製品が同じ配慮をするとは限りません。「夜間スキャンのたびにネットワークとディスクが張り付く」「オンライン専用にしたファイルが翌朝すべて実体化している」ときは、スキャン側の動きも調べます。¹³

6. アプリ開発側の対策 ── 不用意に開かず、保存先を分ける

6.1. 列挙時に属性を確認し、中身が必要なファイルだけを読む

基本方針は、プレースホルダーを「取り寄せコストのあるファイル」として扱うことです。ログ収集、ハッシュ計算、プレビュー生成など、必須でない処理にはスキップする選択肢を持たせます。

次は、属性を確認してからCSVを取り込む例です。

// .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);
}

この例は、オンライン専用の可能性があるファイルを今回は処理しない方針です。業務上必ず取り込む必要があるファイルまで、警告ログだけで処理済みにしてはいけません。事前に実体を確保する運用と、読み取り失敗時の扱いを合わせて決めます。

6.2. FILE_FLAG_OPEN_NO_RECALLを「通信しない保証」にしない

CreateFile の FILE_FLAG_OPEN_NO_RECALL は、要求したデータをリモート側に置いたままとし、ローカルストレージへ戻さない意図を示すフラグです。中身を読むためのデータ転送そのものを禁止するフラグではありません。¹⁴

帯域や待ち時間を避けたい調査では、属性・サイズ・タイムスタンプなどのメタデータだけで済ませます。列挙結果の情報を使う、必要に応じてアクセス権0で開いて属性を取得するなど、読み取りアクセスを要求しない方法を選びます。¹⁴

6.3. データ配置と、失敗時の案内を仕様に含める

KFM環境では「ドキュメント」もOneDrive配下になり得ます。アプリの設定・データベース・作業ファイルは %ProgramData% や %LocalAppData% など用途に合う場所に置き、既定の保存先・取込先に安易にデスクトップやドキュメントを選ばないようにします。具体的な判断は「Windowsアプリのデータ保存先の選び方」にまとめています。

ユーザーが保存先を選べる場合も、OneDrive配下を選んだときの挙動を決めておきます。OneDrive / OneDriveCommercial の環境変数で分かる同期ルートを手掛かりに警告する、ロックファイルやDBの配置は拒否する、といった判断を仕様に含めます。

読み取りに失敗したときは、対象パスとエラーコードに加え、OneDrive配下であることが分かれば、その情報も表示・記録します。0x8007016A などを検知した場合に「OneDriveの状態を確認してください」と案内できるだけでも、現場とヘルプデスクが同じ確認手順で調べやすくなります。

7. 情シス側の対策 ── ピン留めとポリシーで状態を維持する

7.1. 必要なフォルダーだけをピン留めする

ファイル オンデマンドを全体で無効にする前に、業務アプリが読むフォルダーを「常にこのデバイス上に保持する」にします。キッティング時に attrib +p -u <フォルダー> /s /d を使う場合も、ダウンロードの完了を確認してから業務へ引き渡します。⁶⁴

「一度開いておいた」だけでは、後の自動解放を防げません。必要な場所をフォルダー単位でピン留めし、その状態をサポート手順にも含めることがポイントです。

7.2. KFMとファイル オンデマンドを意図して構成する

「気づいたら有効だった」を避けるため、グループポリシーやIntuneで設定を統制します。元に戻す操作を禁止するポリシーもあるため、端末の画面だけでなく、組織で適用している設定も確認します。⁸¹

DehydrateSyncedTeamSites は、同期済みチームサイトの実体を減らす方向に働くポリシーです。必要なファイルが雲マークへ戻る場合は、ユーザーの「空き領域を増やす」操作だけでなく、こうした組織設定も確認します。⁸

7.3. ストレージセンサーと全量同期のコストを確認する

ストレージセンサー(Storage Sense)には、一定日数開かれていないクラウドファイルをオンライン専用に戻す機能があります。ConfigStorageSenseCloudContentDehydrationThreshold で日数を構成でき、同ポリシーの既定値0は自動で戻さない設定です。ただし、ユーザーが設定画面で有効化していたり、組織で低容量端末向けに構成していたりする場合があります。¹⁰

対象になるのは、明示的にピン留めされていない「ローカルで利用可能」なファイルです。ピン留めされたファイルは自動解放の対象外なので、「先週まで開けたのに雲マークへ戻った」ときは、本当にP属性が付いていたかを確認します。⁴

FilesOnDemandEnabled を無効にすると従来型の全量ダウンロード同期になりますが、ディスク消費と初回同期の帯域負荷が増えます。Microsoftは有効のままの運用を推奨しています。無効化は、対象ユーザーのデータ量とディスク容量を確認したうえでの限定的な措置と考えてください。⁸⁴

問い合わせテンプレートには、2章の「パス → 属性 → OneDrive稼働 → ネットワーク → 空き容量 → 記録」を組み込みます。担当者が変わっても、設定をむやみに切り替えず、同じ順序で原因を調べられるようにしておきます。

8. まとめ

OneDrive環境のファイル障害は、まず「場所が変わったのか」と「中身の取り寄せが必要なのか」を分けると整理できます。KFMには既知フォルダーAPIによるパス解決で対応し、ファイル オンデマンドには属性を確認してから必要な中身だけを読む設計で対応します。

そのうえで、監視先への書き戻し、長時間の排他ロック、全件スキャンといった処理が同期とどう重なるかを見直します。アプリの内部データはOneDrive配下から分け、業務上必要なファイルはピン留めとポリシーで実体を維持する。この役割分担が、応急処置で終わらせないための基本です。

次に「ファイルはあるのに読めない」という相談を受けたら、最初に問い直してください。

アプリは、いまの正しい場所を見ているか。そして、そのファイルの中身は、本当にローカルにあるか。

関連記事

• Windows I/Oの深層(第5回) ── NTFSの内部構造:MFTから理解するファイルシステム
• FileSystemWatcher実務ガイド - 取りこぼしと重複対策
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス
• Windowsアプリのデータ保存先の選び方 ── SQLite / JSON / レジストリ / Access 判断表
• MAX_PATHとWindowsのパス・ファイル名の落とし穴 ── 260文字制限、予約名、末尾ドット、大文字小文字

関連する相談領域

合同会社小村ソフトでは、「今まで動いていた取込処理がPC入れ替え後に動かない」「特定のPCでだけファイルが読めない」といったOneDrive・クラウドストレージ絡みの業務アプリの不具合調査、プレースホルダーを前提にしたファイル処理・監視処理の設計と改修、KFM・ファイル オンデマンド環境での保存先設計のレビューを扱っています。現象の切り分けからで構いませんので、お気軽にご相談ください。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

デスクトップに置いたCSVを業務アプリが「ファイルが見つかりません」と言って読めません。なぜですか？

多くの場合、デスクトップフォルダー自体がOneDriveの「既知のフォルダーの移動(KFM)」によって C:\Users\<ユーザー名>\OneDrive\デスクトップ 配下に移動しているか、ファイルがオンライン専用のプレースホルダーになっていることが原因です。アプリが 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管理下に置かない設計に直すのが確実です。

「常にこのデバイス上に保持する」にしたのに、いつの間にか雲マークに戻るファイルがあります。なぜですか？

まず、そのファイルに本当にピン留め(P属性)が付いているかをattribコマンドで確認してください。ピン留めされたファイルはストレージセンサーの自動的なオンライン専用化の対象外ですが、ピン留めせずに開いただけの「ローカルで利用可能」なファイルは、ストレージセンサーの設定やポリシーによって一定期間後にオンライン専用へ戻されることがあります。ほかにも、ユーザー自身の「空き領域を増やす」操作や、チームサイトをオンライン専用化するポリシー(DehydrateSyncedTeamSites)でも雲マークに戻ります。業務上必ずローカルに必要なフォルダーは、フォルダー単位でピン留めして運用してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。