如何通过Graph API/SDK检查OneDrive文件是否被锁定或打开

Great question! Using the Checkout() API to test for locks does feel like a bit of a workaround—let’s look at a cleaner, more intentional way to check if a OneDrive file is locked before attempting deletion with the Microsoft Graph SDK for C#.

The Better Approach: Query DriveItem Lock Status Directly #

Microsoft Graph exposes lock information directly on the DriveItem resource through the lock property (of type ItemLock). When a file is open in an application like Microsoft Office (which applies an exclusive write lock), this property will be populated with details about the lock, including who locked it and the lock type.

Instead of using a write operation (like checkout) to test the lock state, we can make a read-only query to fetch just the lock metadata. This is more elegant because it doesn’t modify the file’s state and gives us explicit information about the lock.

C# SDK Code Example #

Here’s how to implement this:

using Microsoft.Graph;
using System.Net;

// ... your existing Graph client setup

try
{
    // Fetch only the lock and file properties to minimize payload size
    var driveItem = await graphClient.Drives[driveId].Items[driveItemId]
        .Request()
        .Select("lock,file") // Request only the properties we need
        .GetAsync();

    // Check if the item has an active lock
    if (driveItem.Lock != null)
    {
        var lockedByUser = driveItem.Lock.LockedByUser?.DisplayName ?? "an unknown user";
        Console.WriteLine($"Cannot delete file: It's locked by {lockedByUser}. Please close the file and try again.");
        return;
    }

    // Proceed with deletion if no lock is present
    await graphClient.Drives[driveId].Items[driveItemId].Request().DeleteAsync();
    Console.WriteLine("File deleted successfully!");
}
catch (ServiceException ex)
{
    // Handle race condition: file might get locked between our check and deletion
    if (ex.StatusCode == HttpStatusCode.Locked)
    {
        Console.WriteLine("File became locked right before deletion. Please close it and try again.");
    }
    else
    {
        Console.WriteLine($"Unexpected error: {ex.Message}");
    }
}

Why This Is Better Than the Checkout Workaround #

• Read-only operation: Unlike Checkout(), this query doesn’t modify the file’s state (e.g., marking it as checked out), which avoids unintended side effects for other users or processes.
• Explicit lock details: You get direct access to who locked the file, the lock type, and expiration time (if applicable), which lets you provide more informative error messages to users.
• RESTful design: This aligns with best practices—using GET requests to retrieve state, rather than using a POST operation as a test.

Important Note: Race Conditions #

Even with this pre-check, you still need to handle the 423 Locked error in your catch block. There’s a small window between when you check the lock status and when you execute the deletion where the file could be locked by another process. This is a common distributed systems issue, so the exception handling acts as a necessary safety net.

内容的提问来源于stack exchange，提问作者Maryna Shubna