Does FILE_LINK_POSIX_SEMANTICS allow replacing an existing destination opened without FILE_SHARE_DELETE?

Question

Does FILE_LINK_POSIX_SEMANTICS allow replacing an existing destination opened without FILE_SHARE_DELETE?

希望匿名 0

Hello,

I’m trying to clarify the documented Windows/NTFS semantics of POSIX-style hard-link destination replacement.

Consider the following state:

File A already exists at the destination path.
A has an existing open handle.
That handle allows FILE_SHARE_READ, but does NOT allow FILE_SHARE_DELETE.
File B is a distinct file object from A.
A hard-link operation for B targets A’s existing pathname using FILE_LINK_REPLACE_IF_EXISTS together with FILE_LINK_POSIX_SEMANTICS.

My main question is specifically about the existing destination object A:

Is the replacement required to fail because A’s existing handle does not allow FILE_SHARE_DELETE, or do POSIX hard-link replacement semantics permit A’s directory entry to be replaced despite that sharing mode?

I am not looking for a way to bypass sharing restrictions or for instructions to force the operation. I only want to determine what behavior Microsoft specifies for this condition.

The Microsoft documentation I reviewed appears to establish that POSIX link semantics can replace an existing destination and that an existing handle to the old object may remain valid after its name is removed. However, I could not determine whether this also applies when that existing handle explicitly denies FILE_SHARE_DELETE.

If possible, could you please clarify the following points?

Does FILE_LINK_POSIX_SEMANTICS change or override the FILE_SHARE_DELETE compatibility requirement for the existing destination object?
When FILE_LINK_REPLACE_IF_EXISTS targets an existing destination A, is removal/replacement of A’s directory entry subject to the sharing mode of existing handles to A?
Is the ability for an existing handle to remain valid after POSIX replacement independent from whether the replacement was permitted in the first place under FILE_SHARE_DELETE rules?
Does MS-FSA define a normative share-access or delete-sharing check for the existing destination during POSIX hard-link replacement?
If this behavior differs between the NT native API, NTFS implementation, and MS-FSA protocol semantics, which layer defines the relevant behavior?
Is the result guaranteed by the documented Windows/NTFS contract, or should it be considered filesystem-, Windows-version-, or implementation-dependent?

Relevant Microsoft documentation includes:

FILE_LINK_INFORMATION / FILE_LINK_INFORMATION_EX
FILE_LINK_REPLACE_IF_EXISTS
FILE_LINK_POSIX_SEMANTICS
FileLinkInformation / FileLinkInformationEx
MS-FSA link/replacement processing

A specification-level answer would be especially helpful. For example, whether the documented result is:

A. replacement must fail because the destination denies FILE_SHARE_DELETE;

B. POSIX link replacement may proceed despite that sharing mode;

C. another documented condition determines the result; or

D. this interaction is not specified by the public Windows contract.

Thank you.

0 comments

1 answer

Your answer

Answer 1

The documented public contract supports this conclusion: D. this exact interaction is not fully specified by the public Windows contract.

Supported facts from the documentation:

FILE_LINK_POSIX_SEMANTICS applies only when FILE_LINK_REPLACE_IF_EXISTS is also specified.
With both flags set, the documentation says the operation can replace an existing file even if there are existing handles to it.
After such a replacement, existing handles to the replaced file continue to be valid for operations such as read and write, and subsequent opens of the target name open the new link, not the replaced file.

What the provided documentation does not say:

It does not state that FILE_LINK_POSIX_SEMANTICS overrides or bypasses a FILE_SHARE_DELETE requirement on existing handles to the destination object.
It does not define a normative share-access check against the existing destination file object A during replacement.

What MS-FSA does specify in the provided material:

For FileLinkInformation, when opening the destination directory, the specified ShareAccess is FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE.
In product behavior notes, Windows 11 and earlier and Windows Server 2022 and earlier can fail the operation with STATUS_SHARING_VIOLATION because of how the destination directory is opened:
- for FileLinkInformation, if there is a pre-existing handle with FILE_SHARE_DELETE access on the destination directory;
- for FileRenameInformation, if there is a pre-existing handle with DELETE access on the destination directory.

That is a directory-open behavior note, not a documented rule for the existing destination file object being replaced.

So, for the specific questions:

Does FILE_LINK_POSIX_SEMANTICS change or override FILE_SHARE_DELETE compatibility for the existing destination object?
No such override is stated in the provided documentation.
Is removal/replacement of A’s directory entry subject to the sharing mode of existing handles to A?
The provided documentation does not define that point.
Is handle survival after POSIX replacement independent from whether replacement was permitted in the first place?
Yes, as a specification reading. The docs state what happens if replacement occurs: old handles remain valid and new opens resolve to the new link. They do not state the permission/share conditions that guarantee replacement is allowed against an already-open destination file.
Does MS-FSA define a normative share-access or delete-sharing check for the existing destination during POSIX hard-link replacement?
Not in the provided material. The provided MS-FSA text specifies opening the destination directory and its share access, but not a normative FILE_SHARE_DELETE check for the already-existing destination file object.
Which layer defines the relevant behavior?
In the provided material, the API/structure documentation defines the exposed flag semantics, while MS-FSA defines protocol/file-system algorithm details such as destination-directory opening. For the exact question about an already-open destination file denying FILE_SHARE_DELETE, the provided public material does not define a complete contract.
Is the result guaranteed by the documented Windows/NTFS contract?
No. Based on the provided documentation, the guarantee is limited to the stated POSIX replacement effect once replacement is allowed. The exact interaction with an existing destination handle that does not allow FILE_SHARE_DELETE is not documented here as a guaranteed Windows/NTFS contract.

So the closest specification-level answer is:

Not A: there is no provided documentation stating replacement must fail because the destination denies FILE_SHARE_DELETE.
Not B: there is no provided documentation stating POSIX semantics override that sharing restriction.
Not C: no other decisive documented condition for the existing destination file is provided here.
Therefore D: this interaction is not specified in the provided public documentation.