網路磁碟機與 UNC 路徑的陷阱 ── 業務應用程式處理檔案伺服器(共用資料夾)的實務

「在開發機上明明可以運作,結果客戶環境卻回報『找不到 Z:\ 』」「一放上工作排程器,對共用資料夾的輸出就開始失敗」「改成 Windows 服務之後,就看不到檔案伺服器了」── 在業務應用程式的諮詢案例中,與檔案伺服器(共用資料夾)有關的麻煩堪稱經典中的經典。訂單資料的匯入、報表或 CSV 的輸出、監控設備吐出的檔案 ── 在地端的業務系統中,共用資料夾至今仍是現役的整合基礎設施。

麻煩的地方在於,這類問題大多不是「程式碼的錯誤」,而是根植於 Windows 本身的機制 ── 磁碟機代號與登入工作階段的關係、服務的執行帳戶與驗證、SMB 的連線管理。就算用偵錯器追蹤也找不到原因,時間就在「我的電腦重現不出來」中一點一滴流逝。

本文以實作共用資料夾檔案輸出・匯入・監控的業務應用程式開發者(WinForms/WPF/Windows 服務)為對象,從機制面整理網路磁碟機與 UNC 路徑的陷阱,並將實務上的定石整理成判斷表。

假設的環境

由於驗證相關的討論會因前提不同而答案不同,因此先在此明確列出假設的環境。

是網域環境還是工作群組環境,是本文中影響最大的分歧點。第 3 章的執行帳戶選項(電腦帳戶或 gMSA)必須要有網域才成立;沒有網域的環境,則會偏向第 4 章「明確傳遞認證資訊」的方向。請先確認自家公司屬於哪一種,再繼續閱讀。

本文中使用的縮寫

1. 先講結論

• 磁碟機代號(Z: 等)並非整個系統共用,而是以登入工作階段為單位。每個登入工作階段都會分配到一整套 A 到 Z 的磁碟機代號,因此不同使用者的行程、在不同登入工作階段中執行的服務,都看不到使用者所對應的磁碟機。²
• 啟用 UAC 的系統管理員,會建立一般權限與提升權限用的兩個登入工作階段,磁碟機對應(DosDevices 的符號連結)在各工作階段中是獨立的。因此才會發生「只有從提升權限的應用程式看不到 Z:」的現象。雖然存在透過 EnableLinkedConnections 登錄機碼讓兩個工作階段共用的迴避方法,但 Microsoft 明確指出這是「可能使系統變得不安全,不受支援」的設定。³⁴
• 從服務(或不同安全性內容的行程)存取遠端資源時,官方方針是使用 UNC 路徑(\\server\share\...)。在服務內用 net use 或 WNet 系列 API 對應磁碟機代號的做法,基於認證外洩與服務之間互相干擾的考量,並不建議採用。²
• 在共用端要授予權限的對象,由服務的執行帳戶決定。LocalSystem 與 NetworkService 在網路上會以「電腦的認證資訊」身分進行驗證,LocalService 則會變成匿名認證,不適合用於共用存取。使用本機使用者帳戶的服務,無法存取網路資源。實務上的首選是網域帳戶,或是可以把密碼管理交給 OS 負責的 gMSA(group Managed Service Account,群組受管理服務帳戶)。不過 gMSA 的前提是要有網域環境,並準備好 KDS 根金鑰(第 3 章)。⁵⁶⁷⁸¹⁹
• 無法用多組認證資訊同時連線到同一台伺服器。第二個連線會因錯誤 1219(ERROR_SESSION_CREDENTIAL_CONFLICT)而失敗,這是規格(by design)。¹⁰¹¹
• 共用資料夾「速度慢・會斷線・有時候根本不在」才是正常狀態。閒置的連線在預設情況下,伺服器端會在 15 分鐘後將其中斷(下次存取時會重新連線)。File.Exists 在權限不足或發生錯誤時也不會擲出例外,而是回傳 false,因此無法區分「檔案不存在」與「連不到伺服器」。¹²¹³
• FileSystemWatcher 支援監控網路磁碟機與遠端電腦,但設計時要假設它會漏掉事件。緩衝區溢位時會遺失事件,而透過網路監控時,內部緩衝區上限會被限制在 64KB。併用輪詢(完整掃描)是實務上的定石。¹⁴

2. 磁碟機代號與 UNC 路徑的關係 ── Z: 是「你的登入工作階段」的東西

在檔案總管中把 \\fileserver\share 對應成 Z:,看起來就像整台機器都長出了一個「Z: 磁碟機」。這是最初的誤解。

官方文件的說明相當明確。磁碟機代號並非系統全域共用,而是以登入工作階段為單位,分配到一整套 A 到 Z 的代號。重新導向的磁碟機(網路磁碟機)無法在以不同使用者帳戶執行的行程之間共用,在其他登入工作階段中執行的服務,也無法存取在另一個工作階段中建立的磁碟機代號。² 系統是根據唯一識別登入工作階段的登入 SID 來管理磁碟機對應的。²

也就是說,Z: 只不過是「每個登入工作階段各有一套路徑的縮寫符號」,實體則永遠是 UNC 路徑。畫成圖如下所示。

flowchart TB
    accTitle: 磁碟機代號與 UNC 路徑的關係
    accDescr: 兩個登入工作階段各自擁有獨立的磁碟機代號集合,只有其中一個對應了 Z:,而共用資料夾的實體 UNC 路徑只有一個,兩個工作階段能否用 Z: 到達的結果並不相同
    subgraph SA["登入工作階段 A ── 互動式登入的使用者"]
      EXP["檔案總管<br/>從桌面啟動的應用程式"]
      ZA["這個工作階段的磁碟機代號集合<br/>Z: 已對應到共用資料夾"]
      EXP --- ZA
    end
    subgraph SB["登入工作階段 B ── 服務 / 工作排程器"]
      SVC["Windows 服務<br/>排程執行的批次作業"]
      ZB["這個工作階段的磁碟機代號集合<br/>Z: 尚未指派"]
      SVC --- ZB
    end
    UNC["共用資料夾的實體<br/>UNC 路徑 ── fileserver01 的 share"]
    ZA -->|"可透過 Z: 到達"| UNC
    ZB -.->|"Z: 不存在,只有 UNC 路徑才能到達"| UNC

圖 1:磁碟機代號每個登入工作階段各有一套,而實體的 UNC 路徑只有一個

要注意的是,這種區隔並非「因為使用者不同」。即使把服務設定為以與工作階段 A 相同的使用者帳戶執行,系統仍然會為服務建立新的登入工作階段,因此工作階段 A 中建立的對應不會被繼承。² 「明明把服務的執行使用者設成跟自己一樣,卻還是找不到 Z:」這類諮詢,原因就出在把這一點搞混了。

從這裡開始,可以連鎖式地說明現場經常發生的症狀。

UAC 的部分值得再深入了解一下。當屬於系統管理員群組的使用者登入時,系統會建立兩個相互連結的登入工作階段:一個是權限受限的權杖,另一個是完整的系統管理員權杖。磁碟機對應的實體,是把磁碟機代號與 UNC 路徑對應起來的符號連結物件(DosDevices),這是登入工作階段專屬的,不會在工作階段之間共用。³ 登入指令碼是在一般權限那一側執行,所以從提升權限的行程看不到那個對應,道理就在這裡。

把 EnableLinkedConnections(HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 下的 DWORD 值)設為 1,就會在兩個相互連結的工作階段中都寫入符號連結,這個症狀就會消失。不過官方文件明確指出:「這個迴避方法可能使系統變得不安全。Microsoft 不支援這個迴避方法。使用時請自行承擔風險。」⁴ 在客戶環境的登錄檔中埋入不受支援的設定,作為業務應用程式的解決方案並不是好路子。在應用程式端以 UNC 路徑撰寫才是正道。資料夾重新導向的官方疑難排解文件中也提到「建議一律使用 UNC 路徑,而非磁碟機代號」。⁴

實作上很單純,只要設定檔中儲存的路徑用 UNC 表示即可。

// appsettings.json ── 用 UNC 而非磁碟機代號來表示
{
  "FileTransfer": {
    "IncomingDir": "\\\\fileserver01\\edi\\incoming",
    "ProcessedDir": "\\\\fileserver01\\edi\\processed"
  }
}

如果應用程式允許使用者在資料夾選擇對話方塊中選到 Z: 底下的路徑,那麼儲存時先正規化成 UNC,之後即使執行內容改變也不會出問題。從磁碟機代號轉換成 UNC,有一個現成的 API 叫做 WNetGetUniversalName。¹⁵

3. 從 Windows 服務存取共用資料夾 ── 必須用 UNC,以及「以誰的身分」存取

如前一章所述,服務無法使用對應的磁碟機。官方文件表示,服務(以及在不同安全性內容中執行的行程)應該以 UNC 名稱存取遠端資源,並明確不建議在服務內用 net use 或 WNet 系列 API,在執行階段對應磁碟機代號。文件所列出的理由包括:在相同內容中執行的其他服務也會看到這個對應、傳給 net use 的認證資訊可能外洩到服務邊界之外,以及多個服務嘗試建立相同的對應時,會因「已經連線」的錯誤而互相干擾。²

改用 UNC 路徑之後,接下來的問題就是驗證。服務究竟是「以誰的身分」存取檔案伺服器?這由執行帳戶決定,共用端該授予權限的對象也由此而定。

LocalSystem 與 NetworkService 會「以電腦的身分」連上網路,這是官方明文記載的規格。⁵⁶ BITS 的文件中,把這個結果所衍生的實務注意事項直接寫了出來:「若來源檔案的 ACL 把存取權限限制給特定使用者帳戶,那麼(以電腦認證資訊驗證的)服務就會被拒絕存取」「系統帳戶不應該使用對應的磁碟機」。¹⁷

由此可以導出以下 3 項實務指引。

• 「改成服務後就被拒絕存取」的第一步排查,是確認執行帳戶。在桌面環境執行時,是以「你自己」的權限做存取檢查;而在服務中,則是以上表所列的身分做存取檢查。請針對該身分,同時確認共用的存取權限與 NTFS 的 ACL。
• 若要在網域環境中長期運維,執行帳戶就用網域帳戶或 gMSA。gMSA 由 OS 每 30 天自動更新一次 240 位元組的隨機密碼,因此可以從結構上消除「服務帳戶密碼過期,週一早上全部停擺」這類事故。¹⁶
• 在工作群組環境(沒有網域)中,電腦認證資訊的驗證方式無法成立,因此就輪到下一章介紹的明確傳遞認證資訊登場了。

gMSA 有其前提條件。雖然上面寫成「首選」,但它並不是想到就能馬上使用的東西。gMSA 原本是把單一伺服器用的 sMSA(standalone Managed Service Account)功能,擴充為可以跨多台伺服器使用,是一種提供自動密碼管理與簡化 SPN 管理的網域帳戶。¹ 導入前請先確認以下事項。

這些都是需要與網域管理員協調的項目,因此若要提出以 gMSA 為前提的設計,順序上應先向基礎架構負責人確認上述 5 點。若無法確認,或是 10 小時的等待時間無法納入工程排程,那麼務實的做法是先用一般的網域帳戶搭建,並讓日後切換到 gMSA 只需要變更執行帳戶即可完成。

服務本身的建立方式(執行帳戶設定、復原選項、安全停止)已整理在「Windows 服務的建立與維運 ── 從工作排程器的取捨到 BackgroundService 服務化」中,而工作階段與登入的機制則整理在「如何理解 Windows 的工作階段隔離 ── Session 0・RDP・多使用者同時執行」中。

4. 認證資訊的處理 ── net use・認證管理員・錯誤 1219

若無法直接對執行帳戶本身授予共用端的權限(例如工作群組環境,或 NAS 採用專屬帳戶制的情況),就需要明確傳遞認證資訊來連線。主要有 3 種手段。

• net use \\server\share /user:... ── 在該登入工作階段中建立連線。用於互動式確認很方便,但如前一章所述,不建議在服務內執行。²
• 認證管理員(cmdkey) ── 用 cmdkey /add:server /user:svc-file /pass:... 先儲存起來,之後對該伺服器進行驗證時,就會自動使用已儲存的認證資訊。¹⁸¹⁹ 儲存是以使用者設定檔為單位,因此若要在服務中使用,就必須在「服務執行帳戶的內容(context)下」進行登錄,這是一個容易踩到的陷阱。
• 從程式建立連線(WNetAddConnection2) ── 可以指定用戶端的認證資訊,建立與網路資源之間的連線。官方文件也把它列為伺服器行程存取網路資源的策略之一。²⁰ 若設定為不指派磁碟機代號的「無裝置連線(deviceless connection)」,就能維持以 UNC 路徑存取。

而在這個領域中最有名的陷阱,就是錯誤 1219。

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. (ERROR_SESSION_CREDENTIAL_CONFLICT, 1219)¹¹

無法從同一個登入工作階段,用不同的使用者名稱對同一台伺服器建立多個連線。如果想用「業務共用用自己的帳戶、系統整合用的共用用專用帳戶」這種方式,以兩種認證資訊連到同一台檔案伺服器,第二個連線就會因 1219 而失敗。官方文件明確指出這是「by design(規格如此)」,列出的迴避方法是「用 IP 位址連線」「建立另一個 DNS 別名再連線」── 也就是讓它看起來像是另一台伺服器的方法。¹⁰

在實務上,第一選擇是從一開始就避免對同一台伺服器分別使用多組認證資訊的架構。把整合用的帳戶統整成一個,對所有需要的共用都授予這個帳戶的權限。只有在有無法這麼做的特殊原因時,才用別名(alias)來分開路徑。

不過,別名並不是「在 DNS 加一行 CNAME 就結束了」這麼簡單。在 Kerberos 驗證的環境中,SMB 用戶端會嘗試用對應連線目標名稱的 SPN(服務主體名稱)進行驗證,因此若沒有替別名註冊 SPN,經由 CNAME 的存取本身就可能失敗。官方的疑難排解文件也把 SPN 缺失列為原因之一,並建議不要用 DNS 的 CNAME,而是用 netdom computername <伺服器名稱> /add:<別名> 把它設定為電腦名稱的別名。²¹ 若要把經由別名的連線,當作 1219 的對策納入設計,務必先在目標環境中實際驗證是否可行。

另外,「服務想要以連線進來的用戶端使用者的權限存取檔案伺服器」這種進階需求,不屬於重複使用認證資訊的範疇,而是偽裝(impersonation)的領域。官方文件也建議與其讓服務抱著認證資訊不放,不如使用偽裝。² 偽裝的正確寫法,以及在遠端資源上需要額外考量的地方,請參考「正確處理 Windows 偽裝權杖 - 執行緒層級的權限借用與安全還原方式」。

診斷自己的環境 ── 該先執行的指令

到目前為止的內容,唯有能在出現症狀的環境中確認狀態,才會真正變成實務。排查的起點是:該行程究竟是以誰的身分在執行,擁有哪些連線。請在與症狀發生時相同的執行內容(context)中,執行以下 3 個指令。

關鍵在於要在相同的內容(context)下執行。就算在自己的桌面上執行 net use,講的也不會是服務所擁有的連線。若想以服務的執行帳戶確認,最確實的做法是在工作排程器中,用相同的帳戶、相同的特殊權限設定,暫時登錄一個像 cmd /c "whoami > C:\temp\who.txt & net use >> C:\temp\who.txt" 這樣的工作,再檢查其輸出檔案。

在手邊重現錯誤 1219

1219 這個錯誤,與其看說明,不如自己動手重現一次,更容易理解。請在已加入網域的端點上,嘗試用不同的認證資訊連到同一台檔案伺服器上的兩個共用。

:: 1) 用自己的帳戶連線到第一個共用(密碼用 * 以提示輸入)
net use \\fileserver01\share1 * /user:CONTOSO\tanaka

:: 2) 嘗試用另一個帳戶,連線到同一台伺服器的另一個共用
net use \\fileserver01\share2 * /user:CONTOSO\svc-file
::    → 這裡就會回傳上面引用的錯誤 1219,無法連線

:: 收尾:切斷這個工作階段的所有網路連線
net use * /delete

重點在於,即使共用不同,只要伺服器相同就會衝突。第一個是 share1、第二個是 share2 都沒有關係,因為限制是以伺服器為單位。反過來說,如果先用 net use \\fileserver01\share1 /delete 切斷第一個連線,再建立第二個連線,就會成功 ── 也就是說,依照順序的不同,有時候會通過,所以會出現開發階段重現不出來、到了正式環境才第一次發生的討厭狀況。若要用 IP 位址或別名作為迴避方法,請別忘記前面提到的 SPN 前提條件。¹⁰²¹

5. 以「速度慢・會斷線・有時候不在」為前提來設計

用對待本機磁碟的感覺寫出來的程式碼,面對共用資料夾時一定會在某處出包。應該當作前提的現實有 3 項。

第一,連線斷開才是正常的。閒置狀態的連線,為了避免浪費伺服器資源,預設會在 15 分鐘逾時後斷開。這就是檔案總管中網路磁碟機圖示上出現紅色叉叉這個熟悉現象的成因,只要下次存取,就會迅速重新連線。¹² 也就是說,「不常存取的業務應用程式,每次存取時都要稍等一下」「監控工具大呼『斷線了!』但實際上沒有損害」這兩種情況,都是符合規格的行為。與其監控連線是否存在,不如以實際的 I/O 是否成功來判斷。

這個逾時時間是可以變更的。不過請注意,伺服器端與用戶端各有一個計時器,以較短的那一個為準。¹²

最容易被忽略的是最後一列。用戶端的預設值是 10 分鐘,比伺服器端預設的 15 分鐘還短,因此就算只延長伺服器端,斷線的行為也不會改變。因為工作階段是以 autodisconnect 與 KeepConn 之中較短的那個值來切斷的。¹²

話雖如此,變更這些設定並非首選。斷線是符合規格的行為,下次存取時就會重新連線,通常不會造成實際損害。只有在遇到「舊應用程式一斷線就掛掉,又動不了」這類特殊情況時,才考慮調整數值,而且這是會影響到其他系統的設定,務必先與伺服器管理員取得共識後再進行。應用程式端應該朝「假設會斷線,並以重試因應」的方向設計,這才是正道。

第二,錯誤呈現的方式並不友善。File.Exists 無論是路徑不正確、權限不足,還是磁碟故障,都不會擲出例外,而是回傳 false。¹³ 在本機環境中,「false 就代表不存在」幾乎不會造成困擾;但面對共用資料夾時,「檔案不存在」與「連不到伺服器/沒有權限」全都被壓縮成同一個 false,因此依 Exists 的結果做業務判斷分支的程式碼,會在網路故障時以「找不到目標」正常結束,這是一種令人討厭的損壞方式。不做存在確認、直接嘗試開啟並用例外來區分,對於共用資料夾這種對象而言,是更容易診斷的設計。

第三,對方有時候還不存在。機器剛開機時,服務的啟動有時會搶在網路準備完成之前,檔案伺服器那一端也可能正在重新啟動。持續連線(persistent connection)是在使用者登入時才會被還原的機制²³,因此在不經過登入的服務世界裡,「一啟動就能看到共用」這件事沒有任何保證。正確的行為不是啟動時只做一次通訊確認,失敗就結束,而是一邊重試一邊等待。

把這 3 點納入考量後,寫入端的骨架就會變成這樣。

// 暫時性的網路錯誤就重試,業務錯誤則立即失敗
private static async Task WriteToShareAsync(string finalPath, byte[] content, CancellationToken ct)
{
    var dir = Path.GetDirectoryName(finalPath)!;
    var tempPath = Path.Combine(dir, $"~{Guid.NewGuid():N}.tmp");

    try
    {
        for (var attempt = 1; ; attempt++)
        {
            try
            {
                await File.WriteAllBytesAsync(tempPath, content, ct);
                File.Move(tempPath, finalPath); // 在同一目錄內 rename,公開「完成」狀態
                return;
            }
            catch (IOException ex) when (attempt < 5 && IsRetryable(ex))
            {
                // 只針對暫時性的網路故障,以指數退避重試(有上限)
                _logger.LogWarning(ex, "寫入共用資料夾失敗(第 {Attempt} 次)。將重試", attempt);
                await Task.Delay(TimeSpan.FromSeconds(Math.Pow(2, attempt)), ct);
            }
        }
    }
    catch
    {
        // 放棄並讓例外往外傳播時,盡力(best-effort)清除暫存檔
        try { File.Delete(tempPath); } catch { /* 清除失敗就忽略 */ }
        throw;
    }
}

// IOException 不論是「網路斷線」「目標位置已有同名檔案」還是「磁碟已滿」,都會以相同型別擲出。
// 透過 HResult 的低 16 bit(Win32 錯誤碼),只挑出重試才有意義的暫時性故障
private static bool IsRetryable(IOException ex)
{
    var win32 = ex.HResult & 0xFFFF;
    return win32 is 53   // ERROR_BAD_NETPATH: 找不到網路路徑
              or 59   // ERROR_UNEXP_NET_ERR: 未預期的網路錯誤
              or 64   // ERROR_NETNAME_DELETED: 網路名稱已無法使用
              or 121; // ERROR_SEM_TIMEOUT: 逾時(所謂的號誌逾時)
}

不要粗略地寫成「只要是 IOException 就重試」,這點也很重要。目標位置已有同名檔案、路徑太長、磁碟已滿之類不管重試幾次結果都不會變的失敗,也會以同樣的 IOException 送達,因此如果只靠例外的型別來判斷,就會把永久性的錯誤重試 5 次,白白等待退避時間。請像上面的範例一樣,用 Win32 錯誤碼(53/59/64/121 等,屬於共用存取斷線・逾時系列²⁴),只篩選出「重試才有意義的失敗」。實務上比較務實的做法,是在正式環境的日誌中觀察到新的錯誤碼後,再逐步補進清單。

重點與其說是加上重試這件事本身,不如說是要搭配一套即使重試也很安全的交接協定(temp -> rename、idempotency)。若在寫入途中斷線,就會留下寫到一半的檔案。只要事先約定 final 名稱只會在「關閉後執行 rename」時才會出現,就能防止接收端讀到還沒烤熟的檔案這種事故發生。另外,行程當機或斷電時,程式碼內的清理動作本身不會執行,因此交接用的資料夾也應該一併準備「定期清除 ~*.tmp 中一段時間沒有更新的檔案」這種定期清潔機制,才不會因為垃圾檔案堆積而卡住。這套交接設計的整體樣貌,整理在「檔案整合的互斥控制基礎 - 檔案鎖與原子性 claim 的最佳實務」之中。

還有一個網路對象特有的注意事項。「失敗」這個結果,並不保證真的失敗了。若伺服器端完成 rename 後立刻斷線,可能會發生用戶端收到例外,但 final 名稱的檔案其實已經公開了這種狀態。若什麼都不考慮就直接重試,不是卡在「目標位置已有同名檔案」的錯誤,就是在接收端已經匯入第一個檔案的情況下,把同一份資料重複公開兩次。對策是,在重試 rename 階段的失敗之前,先確認並比對目標位置的狀態。若在 final 名稱中包含處理 ID(單據編號或執行用 GUID),就能判定「已經存在相同 ID 的 final 檔案 = 上次的 rename 其實已經成功」,以成功狀態結束;接收端也能利用 ID 重複來擋下重複匯入。

6. 透過 SMB 的互斥控制與 FileSystemWatcher 的可靠性

6.1. 不可過度信任鎖定

共用資料夾會同時被多個用戶端存取。用 FileShare.None 開啟的話,開啟期間的互斥即使透過 SMB 也能運作,但若設計上過度依賴「拿得到鎖就安全」的想法,在斷線導致控制代碼遺失時,或是混入不使用鎖定的對象(手動複製、其他系統)時,就會崩潰。互斥的本體不應該放在 OS 的鎖定上,而應該放在 temp -> rename・原子性 claim(從 incoming 到 processing 的 rename,只有贏家才處理)・idempotency 這種交接協定這一側。詳細的思考方式,請參考上面提到的互斥控制文章。

6.2. 在遠端共用中使用 FileSystemWatcher 的現實情況

官方文件明確指出,FileSystemWatcher 不僅支援本機,也支援監控網路磁碟機與遠端電腦上的檔案。¹⁴ 使用它本身是正當的做法。不過在可靠性上有 2 個前提。

• 通知是透過緩衝區傳遞的,一旦溢位就會漏掉。若變更在短時間內集中發生,超過緩衝區大小的事件就會遺失。¹⁴
• 透過網路監控時,InternalBufferSize 的上限會被限制在 64KB。官方文件明文記載了這個比本機環境「塞不下更多」的限制。¹⁴

此外,在共用另一端發生伺服器重新啟動或斷線時,監控就這樣悄悄死掉、完全沒有通知傳來的症狀,在不具合調查(缺陷調查)的現場已經反覆見過。把遠端共用的 FileSystemWatcher 定位為「用來提早察覺的提示」,並以啟動時・發生錯誤時・定期的完整掃描(輪詢)作為真實來源,是實務上的結論。包含事件重複、順序錯亂的因應方式在內的設計模式,已在「FileSystemWatcher 的使用方法與注意事項 - 漏掉、重複通知、完成判定的陷阱」中詳述。

7. 實務的定石(判斷表)

把到目前為止的內容,整理成設計時容易猶豫不決的論點的判斷表。

最後一列補充說明一下。共用資料夾整合雖然簡便,但隨著存取來源增加,「誰用什麼權限」「誰跟誰會衝突」的管理難度會呈指數成長。超過某個規模之後,就把接觸檔案伺服器的行程集中成一個 Windows 服務,各用戶端改用 HTTP 或 gRPC 溝通。把共用資料夾從「系統之間的介面」降級為「該服務的內部實作」,是長期而言最容易維護的形態。

8. 總結

• 磁碟機代號只不過是以登入工作階段為單位的符號。別的使用者・提升權限的行程・服務看不到它,這是規格如此,應用程式應該用 UNC 路徑撰寫才是正道。EnableLinkedConnections 是不受支援的迴避方法。
• 從服務存取共用時,必須使用 UNC。以誰的身分驗證,由執行帳戶決定:LocalSystem/NetworkService 是電腦認證資訊,LocalService 是匿名。實務上會對網域帳戶或 gMSA 授予共用端的權限。
• 對同一台伺服器同時使用多組認證資訊連線,會因錯誤 1219 而失敗(規格如此)。應該從設計階段就用帳戶集中或 DNS 別名來迴避。
• 共用「速度慢・會斷線・有時候不在」才是正常狀態。閒置切斷(預設 15 分鐘)並不是異常,File.Exists 回傳的 false 也無法與網路故障區分。應該把重試、temp -> rename、idempotency 一起搭配導入。
• FileSystemWatcher 雖然支援遠端監控,但因為有緩衝區溢位導致的漏失,以及 64KB 的上限,併用完整掃描是實務上的定石。
• 猶豫不決時,請參考第 7 章的判斷表。當規模成長後,也請考慮把接觸共用的行程集中到中介服務的架構。

相關文章

• 檔案整合的互斥控制基礎 - 檔案鎖與原子性 claim 的最佳實務
• FileSystemWatcher 的使用方法與注意事項 - 漏掉、重複通知、完成判定的陷阱
• Windows 服務的建立與維運 ── 從工作排程器的取捨到 BackgroundService 服務化
• 如何理解 Windows 的工作階段隔離 ── Session 0・RDP・多使用者同時執行
• 正確處理 Windows 偽裝權杖 - 執行緒層級的權限借用與安全還原方式

相關諮詢領域

合同會社小村軟體提供透過共用資料夾進行檔案整合系統的設計・實作、伴隨 Windows 服務化而來的存取權・驗證相關架構檢討,以及「改成服務後就看不到共用」「只在特定環境下失敗」之類缺陷的調查。

• Windows 應用程式開發
• 缺陷調查・原因分析
• 技術諮詢・設計審查
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

為什麼從 Windows 服務無法存取網路磁碟機(Z:)?

因為磁碟機代號不是整個系統共用的,而是以登入工作階段為單位。使用者在檔案總管中對應的 Z:,只不過是屬於該使用者登入工作階段的符號,在不同登入工作階段中執行的服務看不到它。即使服務是以使用者帳戶執行,系統仍會為服務建立新的登入工作階段,因此就算帳戶相同,桌面端的對應也不會被繼承。從服務端應該以 \\server\share 的 UNC 路徑存取,這才是正確做法。

以 LocalSystem 執行的服務,該如何存取共用資料夾?

LocalSystem 在網路上會以電腦的認證資訊進行驗證。若是網域環境,只要在共用端(共用的存取權限與 NTFS 的 ACL)對該機器的電腦帳戶(DOMAIN\MACHINE$)授予權限,就能存取。不過更換機器時就得重新設定權限,運維上不太方便,因此實務上建議把服務的執行帳戶設為網域帳戶或 gMSA(群組受管理服務帳戶),並對該帳戶授予共用端的權限。

可以用 FileSystemWatcher 監控共用資料夾上的檔案嗎?

可以使用,但請不要單獨信任它。FileSystemWatcher 支援監控網路磁碟機與遠端電腦,但由於變更通知是透過緩衝區傳遞,一旦通知集中發生,緩衝區就會溢位,導致漏掉事件。而且透過網路監控時,緩衝區上限會被限制在 64KB。應該把通知當作「觸發重新掃描的契機」,並且務必併用啟動時・發生錯誤時・定期的完整掃描(輪詢),這是實務上的定石。

要如何讓檔案整合對網路斷線更有韌性?

設計時要把「共用速度慢・會斷線・有時候不在」當作正常狀態。具體來說,寫入時先用暫存檔名寫,關閉後再重新命名以公開(temp -> rename);讀寫都用重試機制包起來,並區分暫時性的網路錯誤與業務錯誤。要注意 File.Exists 即使在無法存取的情況下也會回傳 false,因此無法區分「檔案不存在」與「連不到伺服器」;而讓處理即使重複執行也不會壞掉的 idempotency(冪等性)設計,則是最後一道防線。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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