Does OneDrive Personal guarantee file-level optimistic concurrency with If-Match when updating existing file content?

I am implementing a process that updates existing files in OneDrive Personal using Microsoft Graph v1.0.

The goal is to allow an update only if the eTag obtained when reading the target file still matches the target file's eTag when its content is actually written. If another process has updated the file in the meantime, the write must not overwrite it with stale content.

I would like to implement optimistic concurrency control at the individual target-file level.

I would like clarification on the following three points.

1. Updating the content of an existing file

When using:

PUT /me/drive/items/{item-id}/content

is specifying:

If-Match: {target-file-eTag}

officially supported for OneDrive Personal / Microsoft Graph v1.0?

If supported, are the following operations performed atomically on the server?

• Comparing the supplied eTag with the current eTag of the target file
• Updating the file content

Also, does the API specification guarantee that an eTag mismatch returns 412 Precondition Failed without changing the file content?

2. createUploadSession with deferCommit

I also tested creating an upload session for an existing DriveItem with deferCommit=true.

The observed results were:

• createUploadSession: 200
• Fragment upload: 202
• Explicit final commit: 412 resourceModified

The target child file had the same eTag at all four checkpoints: before session creation, after fragment upload, immediately before commit, and after the commit was rejected. Its content was also unchanged.

In the explicit commit example for OneDrive Personal in Microsoft's official documentation, the final commit is a PUT specifying a path under the parent folder.

If If-Match is specified on this final commit, against which DriveItem's eTag is it evaluated?

• The parent folder
• The existing child file being updated
• Another DriveItem

Please clarify the official specification for this behavior.

3. Microsoft's recommended approach

The requirement I ultimately need to meet is:

Save only if the eTag obtained when reading the target file still matches at the time of the final content update. If another process has modified the target file in the meantime, the write of stale content must be reliably rejected.

Is there a recommended API pattern that officially guarantees this target-file-level concurrency control for OneDrive Personal / Microsoft Graph v1.0?

In particular, I would like to know which of the following should be used:

• PUT /items/{item-id}/content with If-Match
• createUploadSession with If-Match
• Another recommended approach

No actual Drive IDs, Item IDs, eTags, upload URLs, or authentication information are included in this question.

Thank you.