管理檔案鎖定

Azure 檔案儲存體透過下列通訊協定提供雲端檔案共用的存取權：

• 伺服器訊息區 (SMB)
• 網路檔案系統 (NFS)
• FileREST (HTTPS)

本主題描述如何管理 SMB 與 FileREST 之間的檔案鎖定互動。 NFS 檔案共用有不同的鎖定語意，並支援 FileREST API 的子集。 本主題不適用於 NFS 檔案共用。

SMB 檔案鎖定

掛接檔案共用的 SMB 用戶端可以使用檔案系統鎖定機制來管理共用檔案的存取。 其中包括：

• 整個檔案在讀取、寫入和刪除方面的存取共用。
• 對單一檔案內的區域管理讀取和寫入存取的位元組範圍鎖定。

當 SMB 用戶端開啟檔案時，它會同時指定檔案存取和共用模式。 雖然允許所有組合，但 SMB 用戶端通常會使用下列檔案存取選項：

• 沒有： 僅開啟查詢屬性存取的檔案。
• 讀： 開啟檔案以供唯讀存取。
• 寫： 僅開啟檔案以供寫入存取。
• 讀取/寫入： 開啟具有讀取/寫入權限的檔案。
• 刪除： 僅開啟檔案以進行刪除存取。

SMB 用戶端通常會使用下列檔案共用模式：

• 沒有： 拒絕共用目前的檔案。 開啟具有讀取、寫入或刪除存取權之檔案的任何要求都會失敗，直到檔案關閉為止。
• 共用讀取： 允許後續開啟檔案以供讀取。 如果未指定此旗標，開啟檔案以供讀取的任何要求都會失敗，直到檔案關閉為止。
• 共用寫入： 允許後續開啟檔案以供寫入。 如果未指定此旗標，開啟檔案以供寫入的任何要求都會失敗，直到檔案關閉為止。
• 共用讀取/寫入： 允許後續開啟檔案以供讀取或寫入。 如果未指定此旗標，開啟檔案以供讀取或寫入的任何要求都會失敗，直到檔案關閉為止。
• 共用刪除： 允許後續刪除檔案。 如果未指定此旗標，刪除檔案的任何要求都會失敗，直到檔案關閉為止。

SMB 用戶端開啟檔案範例

請考量下列開啟檔案範例：

• 檔案開啟而不共用違規

  • 用戶端 A 會開啟檔案， FileAccess.Read 而 FileShare.Write (在開啟) 時拒絕後續的讀取/刪除。
  • 用戶端 B 接著會使用 FileAccess.Write FileShare.Read 開啟檔案， (在開啟) 時拒絕後續的寫入/刪除。
  • 結果： 這是允許的，因為檔案存取和檔案共用模式之間沒有衝突。

• 因為檔案存取而造成共用違規

  • 用戶端 A 會以 FileAccess.Write 開啟檔案，而 FileShare.Read (在開啟) 時拒絕後續的寫入/刪除。
  • 用戶端 B 接著會使用 FileAccess.Write FileShare.Write 開啟檔案， (在開啟) 時拒絕後續的讀取/刪除。
  • 結果： 用戶端 B 遇到共用違規。 用戶端指定了由先前由用戶端 A 指定的共用模式拒絕的檔案存取。

• 共用違規，因為共用模式

  • 用戶端 A 會開啟檔案， FileAccess.Write 而 FileShare.Write (在開啟) 時拒絕後續的讀取/刪除。
  • 用戶端 B 接著會使用 FileAccess.Write FileShare.Read 開啟檔案， (在開啟) 時拒絕後續的寫入/刪除。
  • 結果： 用戶端 B 遇到共用違規。 用戶端指定共用模式，拒絕對仍在開啟以進行寫入存取之檔案的寫入權限。

FileREST 檔案存取

當您執行 FileREST 作業時，此作業必須遵守針對 SMB 用戶端上開啟的任何檔案所指定的共用模式。 使用下列檔案存取模式來判斷作業是否可以完成：

列出目錄和檔案、 取得檔案屬性和 取得檔案中繼資料 不會在檔案內容上運作。 這些作業不需要讀取存取檔案 (，也就是說，即使 SMB 用戶端已開啟檔案以供獨佔讀取存取) ，這些作業仍會成功。

以下是與 SMB 共用模式互動的 FileREST 要求範例：

• FileREST 取得檔案共用違規

  • SMB 用戶端會開啟檔案， FileAccess.Read 而 FileShare.Write (在開啟) 時拒絕後續的讀取/刪除。
  • REST 用戶端接著會在檔案上執行 取得檔案 作業， (藉此使用 FileAccess.Read 上表中指定的) 。
  • 結果： REST 用戶端的要求失敗，狀態碼為 409 (衝突) ，錯誤碼 SharingViolation 為 。 SMB 用戶端仍然開啟檔案，並拒絕讀取/刪除存取。

• FileREST Put Range 共用違規

  • SMB 用戶端會開啟檔案， FileAccess.Write 而 FileShare.Read (會在開啟) 時拒絕後續的寫入/刪除。
  • REST 用戶端接著會在檔案上執行 Put Range 作業， (因此使用 FileAccess.Write 上表中指定的) 。
  • 結果： REST 用戶端的要求失敗，狀態碼為 409 (衝突) ，錯誤碼 SharingViolation 為 。 SMB 用戶端仍然開啟檔案，並拒絕寫入/刪除存取。

下一節包含 FileREST API 共用違規案例的完整資料表。

FileREST 上的 SMB 用戶端共用模式含意

根據您在 SMB 用戶端開啟檔案時指定的共用模式，FileREST 可能會傳回狀態碼 409 (衝突) 錯誤碼 SharingViolation 。 下表列出一些案例。

只有在 SMB 用戶端上開啟檔案時，Azure 檔案儲存體才會傳回共用違規。 若要讓 FileREST 刪除檔案 作業成功，沒有針對該檔案開啟控制碼的 SMB 用戶端。 如需詳細資訊，請參閱 Delete File Operation and Interaction between FileREST and SMB opportunistic locks。

FileREST 租用檔案 API 上的 SMB 檔案鎖定含意

根據您在 SMB 用戶端開啟檔案時指定的檔案存取選項，FileREST 租用檔案 API 可能會傳回狀態碼 409 (衝突) ，錯誤碼 SharingViolation 。 下表提供進一步的資訊：

只有在 SMB 用戶端上開啟檔案時，Azure 檔案儲存體才會傳回共用違規。 請注意，若要讓 FileREST 租用檔案 作業成功，沒有針對該檔案開啟寫入或刪除控制碼的 SMB 用戶端。 如需詳細資訊，請參閱 租用檔案 作業和 FileREST 與 SMB 商機鎖定之間的互動。

FileREST 租用檔案對 SMB 檔案鎖定的影響

檔案上的租用提供檔案的獨佔寫入和刪除存取權。 當 SMB 用戶端開啟檔案時，它必須遵守 FileREST 租用檔案作業所租用之任何檔案的鎖定。 您可以使用下表來判斷是否可以完成 SMB 開啟的檔案作業：

FileREST 上的 SMB 刪除含意

當 SMB 用戶端開啟要刪除的檔案時，它會將檔案標示為 擱置刪除，直到該檔案上所有其他 SMB 用戶端開啟控制碼關閉為止。 當檔案標示為擱置刪除時，該檔案上的任何 FileREST 作業都會傳回狀態碼 409 (衝突) ，錯誤碼 SMBDeletePending 為 。 未傳回狀態碼 404 (找不到) ，因為 SMB 用戶端可以在關閉檔案之前移除擱置的刪除旗標。 換句話說，狀態碼 404 (找不到) 只有可能在檔案已移除時出現。

當檔案處於 SMB 擱置刪除狀態時，其不會包含在結果中 List Files 。

另請注意，FileREST Delete File 和 Delete Directory 作業會以不可部分完成的方式認可，而且不會產生擱置的刪除狀態。

FileREST 上的檔案屬性含意

SMB 用戶端可以讀取和設定檔屬性，包括：

• 封存
• 唯讀
• Hidden
• 系統

如果檔案或目錄標示 為唯讀，則嘗試寫入檔案的任何 FileREST 作業都會失敗，狀態碼 412 (前置條件失敗) ，錯誤碼 ReadOnlyAttribute 。 這些作業包括：

• Create File
• Set File Properties
• Set File Metadata
• Put Range

這些檔案屬性無法設定或讀取 REST 用戶端。 將檔案設為唯讀之後，REST 用戶端將無法寫入檔案，直到 SMB 用戶端移除唯讀屬性為止。

FileREST 與 SMB 機會鎖定之間的互動

SMB 隨機鎖定 (oplock) 是 SMB 用戶端所要求用以改善效能並減少網路傳輸的快取機制。 SMB 用戶端可以快取特定檔案或目錄的最新狀態。 隨機鎖定有多種類型，統稱為 SMB 租用類型：

• 讀取 (R) ：SMB 用戶端可以從本機快取讀取。
• 寫入 (W) ：SMB 用戶端可以在本機寫入，而不需要將資料排清回 Azure 檔案共用。
• 處理 (H) ：關閉控制碼時，不需要 SMB 用戶端立即通知 Azure 檔案共用。 當應用程式繼續開啟和關閉具有相同存取和共用模式的檔案時，此鎖定類型很有用。

這些租用類型與指定的存取和共用模式無關。 一般而言，SMB 用戶端會在對檔案開啟新的控制碼時嘗試取得所有租用類型，而不論存取和共用模式為何。

視呼叫的 FileREST 作業而定，您可能需要要求中斷現有的商機鎖定。 在寫入 oplock 的情況下，SMB 用戶端必須排清 Azure 檔案共用的快取變更。 必須中斷各種 oplock 的情況包括：

• 每當發出寫入作業時，必須中斷讀取 (R) oplock，例如 Put Range 。

• 每當發出讀取作業時，必須中斷寫入 (W) oplock，例如 Get File 。

• 每當用戶端發出刪除作業時，必須中斷控制碼 (H) oplock。 Azure 檔案儲存體要求刪除作業成功時，無法開啟任何控制碼。

  當 FileREST 作業面臨與現有 SMB 控制碼的共用違規時，控制碼作業也會中斷。 這會發生在用戶端上執行的應用程式是否仍會開啟控制碼。

中斷 oplock 可能需要排清快取的 SMB 用戶端變更，這可能會導致作業回應時間延遲。 排清可能會導致作業失敗，狀態碼為 408 (要求逾時) ，以及錯誤碼 ClientCacheFlushDelay 。

下列各節將討論作業鎖定中斷的案例。

需要 Oplock 中斷和 SMB 用戶端排清，而 REST 用戶端遇到延遲

請考慮下列範例：

1. SMB 用戶端開啟檔案、取得 RWH oplock，並在本機寫入資料。

2. REST 用戶端會傳送 Get File 要求。

   • Azure 檔案共用會中斷寫入 (W) oplock，讓用戶端具有 RH oplock。
   • SMB 用戶端會針對 Azure 檔案共用排清其快取的資料，並確認 oplock 中斷。
   • Azure 檔案共用會 Get File 處理要求，並使用要求的資料回應。

在此範例中，REST 用戶端會遇到延遲。 這種情況是由 oplock 中斷所造成，而 SMB 用戶端針對 Azure 檔案共用排清其資料所花費的時間。

後續呼叫 Get File 不會發生任何其他延遲，因為寫入 (W) oplock 已中斷。

oplock 中斷是必要的，但 REST 用戶端將不會經歷延遲

請考慮下列範例：

1. SMB 用戶端已取得 RH oplock。

2. REST 用戶端會傳送 Put Range 要求。

   • Azure 檔案共用會將 oplock 中斷要求傳送至 SMB 用戶端，且不會等候回應。
   • Azure 檔案共用會處理 Put Range 要求。

在此範例中，需要 oplock 中斷，但 Put Range 要求不會經歷任何其他延遲。 中斷讀取 oplock 時不需要回應。

Azure 檔案儲存體行為

下表摘要說明每個 FileREST 作業Azure 檔案儲存體的行為。 此行為是以已取得相同檔案控制碼之 SMB 用戶端的 oplock 狀態為基礎。 此外，行為假設 SMB 控制碼存取和共用不會與 FileREST 作業衝突。

如果沒有衝突，控制代碼 oplock 也會中斷，以確保控制代碼在用戶端上仍開啟。 在封鎖的 oplock 中斷的情況下，Azure 檔案儲存體必須等候確認中斷成功。 在非封鎖的 oplock 中斷的情況下，Azure 檔案儲存體不需要等候。

在某些情況下，需要封鎖的 oplock 中斷時，FileREST 作業會失敗。 如果中斷在指定的要求逾時內未成功，或在第 30 秒內完成，服務會傳回狀態碼 408 (要求逾時) ，以及錯誤碼 ClientCacheFlushDelay 。

要求 Delete File 也需要中斷 oplock 控制碼 (H) 租用。 中斷控制碼可確保當 REST 用戶端呼叫 Delete File 時，SMB 用戶端應用程式仍不會開啟任何檔案控制碼。 如果有共用違規，要求會失敗，狀態碼為 409 (Conflict) ，錯誤碼 SharingViolation 。

另請參閱

Azure 檔案儲存體概念