NtCreateFile: Is FILE_DIRECTORY_FILE compatible with FILE_OPEN_REPARSE_POINT for secure directory creation?

Dear Microsoft Windows Developer Support Team,

Thank you for your detailed technical response and for conducting the concurrency tests on Windows 11 with NTFS.

We particularly appreciate the experimental verification of NtCreateFile with CreateOptions 0x00200021, including the parent-directory substitution tests, junction conversion tests, and independent directory identity verification.

Your findings have provided valuable information for our implementation review.

We understand that the successful test results demonstrate observed behavior on the tested Windows build and filesystem, but do not constitute an official Microsoft support guarantee.

Before finalizing our design, we would appreciate clarification on the following remaining points.

1. Production Suitability of NtCreateFile CreateOptions 0x00200021

Our application is a commercial Windows desktop application intended for deployment across multiple customer environments.

The proposed implementation uses:

• FILE_DIRECTORY_FILE

FILE_SYNCHRONOUS_IO_NONALERT

FILE_OPEN_REPARSE_POINT

Combined CreateOptions: 0x00200021

A retained parent-directory handle through OBJECT_ATTRIBUTES.RootDirectory

A fixed single-component relative directory name

FILE_CREATE for strict collision handling

A protected security descriptor applied during creation

Independent reopening and directory identity verification

Given that the combination works in your tests but is not explicitly documented as compatible, could you clarify whether it is reasonable to rely on this behavior in a production application?

Specifically, is the omission of FILE_OPEN_REPARSE_POINT from the compatible-options list an intentional restriction, a documentation limitation, or an implementation detail that should not be relied upon?

If this cannot be determined from the published documentation, we would appreciate confirmation that the support status remains unresolved.

2. Parent-Handle Binding and Concurrent Namespace Modification

Your concurrency tests were particularly helpful.

We understand that no unintended creation at the junction target was observed during your testing.

However, our primary security requirement is stronger than detecting a mismatch after creation.

We need to ensure that directory creation either:

Occurs beneath the directory object referenced by the retained parent handle; or

Fails safely without creating a directory at an unintended location.

Could you clarify whether Windows provides any documented contract establishing this behavior when the parent directory's namespace entry is concurrently renamed, replaced, or converted into a reparse point?

If no such guarantee is documented, is there an alternative supported API or handle-relative operation that provides it?

We understand that comparing volume serial numbers and file IDs after creation is valuable for detecting identity mismatches, but may not independently prevent an unintended creation.

3. Recommended Production Implementation

Our intended implementation requires the following security properties together:

Parent-handle-relative directory creation.

Prevention of unintended reparse-point traversal.

Strict failure when the target name already exists.

Application of a protected security descriptor at creation time.

Independent verification of the created directory's identity.

Predictable failure behavior during concurrent namespace modifications.

If NtCreateFile with CreateOptions 0x00200021 cannot be formally recommended, could Microsoft suggest the closest officially documented and supported implementation approach?

For example, would a particular combination of CreateFileW, CreateDirectoryExW, handle-relative native APIs, and post-creation identity verification be preferable?

We recognize that a higher-level API sequence may not provide exactly the same guarantees. If no fully equivalent supported sequence exists, identifying that limitation would also help our design decision.

4. Engineering Escalation

Since this behavior is relevant to filesystem security and race-condition prevention, we would appreciate clarification from the Windows filesystem/API engineering team.

We understand from your previous response that Microsoft Q&A cannot provide an official product support commitment.

Could you advise whether this question can be referred to the appropriate engineering team through the existing discussion, or whether a separate support case through Microsoft Engage Center is required?

If a formal support case is necessary, please advise the appropriate product/component category for this issue.

Our objective is not merely to identify an implementation that works in testing, but to adopt a documented, maintainable, and supportable security design for deployment across customer Windows environments.

We appreciate your assistance and the time spent investigating this issue.

Thank you.

Best regards,

Software Development TeamDear Microsoft Windows Developer Support Team,

Thank you for your detailed technical response and for conducting the concurrency tests on Windows 11 with NTFS.

We particularly appreciate the experimental verification of NtCreateFile with CreateOptions 0x00200021, including the parent-directory substitution tests, junction conversion tests, and independent directory identity verification.

Your findings have provided valuable information for our implementation review.

We understand that the successful test results demonstrate observed behavior on the tested Windows build and filesystem, but do not constitute an official Microsoft support guarantee.

Before finalizing our design, we would appreciate clarification on the following remaining points.

1. Production Suitability of NtCreateFile CreateOptions 0x00200021

Our application is a commercial Windows desktop application intended for deployment across multiple customer environments.

The proposed implementation uses:

FILE_DIRECTORY_FILE

FILE_SYNCHRONOUS_IO_NONALERT

FILE_OPEN_REPARSE_POINT

Combined CreateOptions: 0x00200021

A retained parent-directory handle through OBJECT_ATTRIBUTES.RootDirectory

A fixed single-component relative directory name

FILE_CREATE for strict collision handling

A protected security descriptor applied during creation

Independent reopening and directory identity verification

Given that the combination works in your tests but is not explicitly documented as compatible, could you clarify whether it is reasonable to rely on this behavior in a production application?

Specifically, is the omission of FILE_OPEN_REPARSE_POINT from the compatible-options list an intentional restriction, a documentation limitation, or an implementation detail that should not be relied upon?

If this cannot be determined from the published documentation, we would appreciate confirmation that the support status remains unresolved.

2. Parent-Handle Binding and Concurrent Namespace Modification

Your concurrency tests were particularly helpful.

We understand that no unintended creation at the junction target was observed during your testing.

However, our primary security requirement is stronger than detecting a mismatch after creation.

We need to ensure that directory creation either:

Occurs beneath the directory object referenced by the retained parent handle; or

Fails safely without creating a directory at an unintended location.

Could you clarify whether Windows provides any documented contract establishing this behavior when the parent directory's namespace entry is concurrently renamed, replaced, or converted into a reparse point?

If no such guarantee is documented, is there an alternative supported API or handle-relative operation that provides it?

We understand that comparing volume serial numbers and file IDs after creation is valuable for detecting identity mismatches, but may not independently prevent an unintended creation.

3. Recommended Production Implementation

Our intended implementation requires the following security properties together:

Parent-handle-relative directory creation.

Prevention of unintended reparse-point traversal.

Strict failure when the target name already exists.

Application of a protected security descriptor at creation time.

Independent verification of the created directory's identity.

Predictable failure behavior during concurrent namespace modifications.

If NtCreateFile with CreateOptions 0x00200021 cannot be formally recommended, could Microsoft suggest the closest officially documented and supported implementation approach?

For example, would a particular combination of CreateFileW, CreateDirectoryExW, handle-relative native APIs, and post-creation identity verification be preferable?

We recognize that a higher-level API sequence may not provide exactly the same guarantees. If no fully equivalent supported sequence exists, identifying that limitation would also help our design decision.

4. Engineering Escalation

Since this behavior is relevant to filesystem security and race-condition prevention, we would appreciate clarification from the Windows filesystem/API engineering team.

We understand from your previous response that Microsoft Q&A cannot provide an official product support commitment.

Could you advise whether this question can be referred to the appropriate engineering team through the existing discussion, or whether a separate support case through Microsoft Engage Center is required?

If a formal support case is necessary, please advise the appropriate product/component category for this issue.

Our objective is not merely to identify an implementation that works in testing, but to adopt a documented, maintainable, and supportable security design for deployment across customer Windows environments.

We appreciate your assistance and the time spent investigating this issue.

Thank you.

Best regards,

Software Development Team

Hi @Suresh kumar V ,

Thank you for the follow-up and for laying out the remaining points so clearly.

On production suitability, the published documentation does not explain why FILE_OPEN_REPARSE_POINT is missing from the options compatible with FILE_DIRECTORY_FILE, so I cannot tell whether it is an intentional restriction, a documentation gap or an implementation detail. I can confirm that, from public sources, the support status of 0x00200021 remains unresolved. Using it in production means relying on behavior that the current NtCreateFile documentation does not cover.

As for parent-handle binding under concurrent rename, replacement or reparse conversion, I did not find any documented contract guaranteeing that the create either happens beneath the object referenced by the retained handle or fails without creating anything elsewhere. I also did not find a supported handle-relative API documented to provide that guarantee. My earlier results remain observations on one configuration, and I agree that comparing identities after creation detects a mismatch but does not prevent it.

For the closest documented approach, none of the options I found provides all six properties together. The same NtCreateFile call without FILE_OPEN_REPARSE_POINT, that is CreateOptions 0x00000021, is a documented combination and keeps parent-relative creation, FILE_CREATE collision handling and the creation-time security descriptor. The documentation does not state how it behaves when the final component already exists as a reparse point, so I compared both option values on the same build, local NTFS, with the same masks as before.

When the final component was already a junction or a directory symbolic link pointing to an existing empty directory, both 0x00000021 and 0x00200021 failed with STATUS_OBJECT_NAME_COLLISION (0xC0000035), and nothing was created in the target. I did not cover a dangling symbolic link, a link whose target does not exist yet, or a link at an ancestor component, and a collision against an existing target does not by itself show whether the link was followed.

I then repeated the two race scenarios with 5,000 creates per scenario for each option value, with a second thread in the same process acting as the competitor under an elevated administrator token. While the parent entry was swapped, all 5,000 creates succeeded for both values. While the held parent was converted in place into a junction, 0x00000021 gave 2,584 successes and 2,416 STATUS_REPARSE_POINT_NOT_RESOLVED failures, and 0x00200021 gave 2,384 and 2,616. The split depends on timing rather than on the flag. In every run, nothing was created at the junction target and every successful create matched its independent reopen.

So in this test, removing FILE_OPEN_REPARSE_POINT did not lead to a create at an unintended location, and I saw no difference that would favor keeping the undocumented combination. The results still do not establish a contract, and they are not enough to say that dropping the flag is safe in the untested cases above.

CreateDirectory2W supports DIRECTORY_FLAGS_DISALLOW_PATH_REDIRECTS, returns a handle and accepts security attributes, but it takes a full path rather than a parent handle. In a separate test on the same build, some calls with that flag failed with error 4395 while a path component was being replaced concurrently, yet still left a directory at the redirected location. So a failed call there should not be read as proof that nothing was created. CreateDirectoryExW is also path-based and returns no handle, which adds a reopen-by-path window.

Whichever creation call you use, the verification step stays the same: keep the creation handle open, compare volume serial number and file ID with an independent reopen as described in FILE_ID_INFO, and check the reparse attribute through FileAttributeTagInfo. This limits the risk but does not provide the predictable concurrent-failure property, and I could not find a supported sequence that does.

On escalation, I am not able to route this forum thread to the Windows filesystem team, so a separate support case through Microsoft Engage Center is the path for an authoritative answer. When opening it, describing the issue as user-mode NtCreateFile reparse handling on NTFS for secure directory creation, and attaching your minimal reproducer along with this thread, should help it reach the right team.

If anything is unclear, please feel free to ask.

Thank you.