OneDrive「隨選檔案」與業務應用 ── 預留位置打破的前提與對策

「業務應用讀不了存在桌面上的 CSV。」「換了電腦之後，一直正常的匯入處理以『找不到檔案』停住。」檔案總管裡明明看得到檔案，於是重新儲存、重新啟動應用都試過，原因還是查不出來。

這時要分開確認的是檔案的位置與內容是否在本機。OneDrive 的「已知資料夾搬移（KFM）」會改變桌面等位置，「隨選檔案」則把內容留在雲端，直到真正需要時才取回。業務應用如果仍以傳統的本機檔案為前提，這兩項都會帶來問題。¹²

本文以中小企業的資訊部門負責人與 Windows 應用開發者為對象，先給出接到諮詢時的釐清步驟，接著整理預留位置的運作機制與屬性的讀法、業務應用會踩到的陷阱，以及開發端和資訊部門各自的對策。

1. 先講結論 ── 把「位置」和「實體」分開確認

檔案在檔案總管裡看得到，既不保證應用引用的路徑正確，也不保證內容能馬上讀到。首先要把下面兩件事分開。

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 底下。下面是路徑的例子。實際的資料夾名稱和同步根目錄會因環境而異，請不要把這些字串原樣寫進程式碼。¹

在新電腦的初始設定（OOBE）中登入 Microsoft 帳戶或公司帳戶時，系統會建議開啟備份，有些設定就這樣一路保持開啟。在組織裡，還可以用 KFMSilentOptIn 原則，在使用者沒有任何操作的情況下一次搬移。不能只設想「使用者是自己有意識地設定的」。¹⁸

麻煩的是，檔案總管裡的樣子幾乎沒有變化。使用 SHGetKnownFolderPath 或 .NET 的 Environment.GetFolderPath 的應用能取到搬移後的路徑。而把 C:\Users\%USERNAME%\Desktop 這類固定路徑寫死在設定檔或程式碼裡的應用，會一直去找搬移前的位置。

也就是說，因應 KFM 首先是路徑解析的問題。確定搬移後的正確路徑之後，再確認這個檔案的內容是否在本機。

3.2. 隨選檔案把「看得見」和「有內容」分成兩件事

在開啟了隨選檔案的環境中，同步範圍內的檔案會顯示在檔案總管裡，而內容可以等到需要時再下載。在其他裝置或網頁上建立的檔案，也會以僅限線上的預留位置形式出現。²⁴

狀態可以透過檔案總管的圖示分辨。⁹

重要的是，開啟過一次得到的「本機可用」，與釘選得到的「一律保留在此裝置上」並不相同。前者可能因為使用者執行「釋放空間」，或者因為儲存感知，再次變回僅限線上。「上個月讀得到」不能作為這次內容仍然留在本機的依據。²¹⁰

stateDiagram-v2
    accTitle: 隨選檔案的三種狀態與轉換
    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 的說明，保存檔案系統標頭大約要用 1 KB。應用嘗試讀取內容時，迷你篩選器會要求同步提供者傳輸資料，等必要的資料送達後讀取才繼續。這種取回稱為補水（hydration），釋放本機實體、讓檔案退回預留位置則稱為脫水（dehydration）。¹¹

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 的資料夾，增加的不只是處理時間，還有流量和本機磁碟消耗。在容量偏小的電腦上，這會因可用空間不足而引出另一類故障。

當應用取回使用者並未明確開啟的檔案時，Windows 可能會顯示通知，向使用者提供封鎖的選項。一旦在那裡被封鎖，該應用之後的下載都會失敗。解除的位置在「設定」的「檔案自動下載」。遇到「只有某台電腦失敗」時，也要確認這個狀態。¹¹

5.3. 沒有考慮附加屬性的程式碼會誤判

像 attributes == FileAttributes.Archive 這樣用完全相等來判斷，會把附帶了其他屬性的檔案當作「非預期」而排除掉。也有備份、同步工具把 OFFLINE 解讀成「已轉存到磁帶」而略過，或者反過來連不必要的檔案都取回的情況。做唯讀檢查或修改封存位元時，不要破壞其他屬性的組合，這一點同樣必要。

Microsoft 給迷你篩選器的指引中有一條提醒：不要對帶有 RECALL_ON_DATA_ACCESS 的檔案輕率地發出讀寫。給核心驅動程式的限制與使用者模式的實作並不相同，但一旦碰到內容就會產生取回成本這一點，業務應用同樣需要留意。¹²

5.4. FileSystemWatcher 也會捕捉到同步的活動

用 FileSystemWatcher 監視 OneDrive 底下時，除了使用者的操作，來自其他裝置的變更同步、補水與脫水引起的屬性和大小更新，同樣可能觸發事件。

而且，如果把匯入結果寫回同一個資料夾，就會形成寫入、上傳、屬性更新、再次觸發事件的迴圈。

flowchart TB
    accTitle: 監視與寫回造成的變更通知迴圈
    accDescr: 收到變更事件的監視應用把匯入結果寫回同一個資料夾，同步應用的上傳和屬性更新會再次觸發事件，形成有如變更通知風暴的迴圈
    ev["變更事件"] --> proc["監視應用執行匯入"]
    proc --> write["寫回同一個資料夾"]
    write --> up["同步應用上傳"]
    up --> attr["屬性和大小被更新"]
    attr --> ev
    sync["其他裝置變更的同步"] -.-> ev

圖 3：把匯入結果寫回被監視的位置，會把同步應用的活動也捲進來，通知可能反覆出現。

需要對事件做稀釋和確認實體的原因，在 FileSystemWatcher 實務指南中做了說明。在 OneDrive 底下，不把通知直接解讀成「又送到一個可以匯入的檔案」的設計就更加重要。

5.5. 獨占鎖定與多台電腦的編輯會與同步衝突

業務應用以獨占鎖定開啟檔案期間，同步應用無法上傳或更新這個檔案。像 Access 的 .accdb、自有格式的資料檔、記錄檔那樣長時間開啟的設計，一旦放在 OneDrive 底下，同步錯誤就會變成常態。

多台電腦編輯同一個檔案時，為了保留雙方的版本，還可能產生帶電腦名稱的檔案或「⋯⋯的複本」這類衝突複本。以「一個資料夾一個檔案」為前提的匯入處理，會因為這種重複而誤動作。鎖定的設計請另見檔案介接互斥控制的基礎知識。

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 環境變數得知的同步根目錄當作線索提出警告、拒絕在那裡放置鎖定檔和資料庫，這類判斷都要寫進規格。

讀取失敗時，除了目標路徑和錯誤碼，如果能判斷出它位於 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 字元限制、保留名稱、結尾句點、大小寫

相關諮詢領域

合同會社小村軟體承接「一直正常的匯入處理在換電腦之後不能用了」「只有某台電腦讀不了檔案」這類與 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 管理之下的設計。

已經設成「一律保留在此裝置上」，卻仍有檔案不知不覺變回了雲朵圖示。這是為什麼？

請先用 attrib 指令確認這個檔案是否真的帶有釘選（P 屬性）。已釘選的檔案不在儲存感知自動轉成僅限線上的範圍內，但只是開啟過、並未釘選的「本機可用」檔案，可能因儲存感知的設定或原則在一段時間後退回僅限線上。此外，使用者自己執行「釋放空間」，或者把小組網站轉成僅限線上的原則（DehydrateSyncedTeamSites），也會讓雲朵圖示回來。業務上必須留在本機的資料夾，請以資料夾為單位釘選後再投入使用。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。