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

Dear Microsoft Windows Developer Support Team,

We are developing a Windows desktop application that requires secure directory creation using native Windows filesystem APIs.

During our implementation review, we identified an ambiguity in Microsoft's published NtCreateFile documentation regarding the compatibility of FILE_DIRECTORY_FILE and FILE_OPEN_REPARSE_POINT.

We have reviewed the official Windows API documentation, relevant Microsoft Q&A discussions, and the Go programming language's Windows filesystem implementation.

We request clarification from the Windows filesystem/API engineering team regarding the following.

1. Exact API Combination

Our proposed implementation uses NtCreateFile with:

• FILE_DIRECTORY_FILE (0x00000001)

FILE_SYNCHRONOUS_IO_NONALERT (0x00000020)

FILE_OPEN_REPARSE_POINT (0x00200000)

Combined CreateOptions: 0x00200021

The operation uses:

A retained parent-directory handle through OBJECT_ATTRIBUTES.RootDirectory.

A fixed single-component relative directory name.

FILE_CREATE for strict collision handling.

An explicit protected security descriptor during creation.

A subsequent independent relative reopen using FILE_OPEN.

Microsoft's published documentation lists options compatible with FILE_DIRECTORY_FILE but does not include FILE_OPEN_REPARSE_POINT.

2. Existing Implementation Evidence

We observed that the Go programming language's Windows implementation uses related combinations:

Go Mkdirat: FILE_DIRECTORY_FILE | FILE_OPEN_REPARSE_POINT

CreateOptions: 0x00200001

Go directory Symlinkat: FILE_DIRECTORY_FILE | FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT | FILE_SYNCHRONOUS_IO_NONALERT

CreateOptions: 0x00204021

Reference: https://go.dev/src/internal/syscall/windows/at_windows.go

We recognize that these implementations do not constitute Microsoft's formal API support commitment and do not exactly match our proposed operation.

3. Clarification Requested

We would appreciate confirmation of the following:

Q1. Is CreateOptions 0x00200021 officially supported for directory creation and reopening through user-mode NtCreateFile?

Q2. If supported, which Windows versions and filesystems are covered?

Q3. When RootDirectory references a retained directory handle and ObjectName contains one relative component, what guarantees exist against unintended reparse-point traversal?

Q4. Does the API guarantee that creation remains bound to the originally opened parent directory, or fails, if another process concurrently substitutes or converts a directory entry into a junction or another reparse point?

Q5. Is OBJ_DONT_REPARSE a supported and documented alternative for this use case?

Q6. If the proposed combination is not officially supported, what alternative API sequence is recommended that preserves all of the following?

Parent-handle-relative directory creation.

Prevention of unintended reparse-point traversal.

Strict collision handling.

Creation-time security descriptor application.

Independent verification of the resulting directory identity.

Q7. Are there any limitations associated with filesystem filter drivers, NTFS reparse points, or specific Windows builds?

4. Requested Engineering Guidance

We would appreciate an authoritative Microsoft API reference, written engineering clarification, or recommendation identifying the supported implementation.

Our objective is to use a documented and maintainable filesystem security design suitable for deployment across customer Windows environments.

We can provide a minimal, non-confidential reproducer if required.

Thank you for your assistance.

Best regards,

Software Development TeamDear Microsoft Windows Developer Support Team,

We are developing a Windows desktop application that requires secure directory creation using native Windows filesystem APIs.

During our implementation review, we identified an ambiguity in Microsoft's published NtCreateFile documentation regarding the compatibility of FILE_DIRECTORY_FILE and FILE_OPEN_REPARSE_POINT.

We have reviewed the official Windows API documentation, relevant Microsoft Q&A discussions, and the Go programming language's Windows filesystem implementation.

We request clarification from the Windows filesystem/API engineering team regarding the following.

1. Exact API Combination

Our proposed implementation uses NtCreateFile with:

FILE_DIRECTORY_FILE (0x00000001)

FILE_SYNCHRONOUS_IO_NONALERT (0x00000020)

FILE_OPEN_REPARSE_POINT (0x00200000)

Combined CreateOptions: 0x00200021

The operation uses:

A retained parent-directory handle through OBJECT_ATTRIBUTES.RootDirectory.

A fixed single-component relative directory name.

FILE_CREATE for strict collision handling.

An explicit protected security descriptor during creation.

A subsequent independent relative reopen using FILE_OPEN.

Microsoft's published documentation lists options compatible with FILE_DIRECTORY_FILE but does not include FILE_OPEN_REPARSE_POINT.

2. Existing Implementation Evidence

We observed that the Go programming language's Windows implementation uses related combinations:

Go Mkdirat:
FILE_DIRECTORY_FILE | FILE_OPEN_REPARSE_POINT

CreateOptions: 0x00200001

Go directory Symlinkat:
FILE_DIRECTORY_FILE | FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT | FILE_SYNCHRONOUS_IO_NONALERT

CreateOptions: 0x00204021

Reference:
https://go.dev/src/internal/syscall/windows/at_windows.go

We recognize that these implementations do not constitute Microsoft's formal API support commitment and do not exactly match our proposed operation.

3. Clarification Requested

We would appreciate confirmation of the following:

Q1. Is CreateOptions 0x00200021 officially supported for directory creation and reopening through user-mode NtCreateFile?

Q2. If supported, which Windows versions and filesystems are covered?

Q3. When RootDirectory references a retained directory handle and ObjectName contains one relative component, what guarantees exist against unintended reparse-point traversal?

Q4. Does the API guarantee that creation remains bound to the originally opened parent directory, or fails, if another process concurrently substitutes or converts a directory entry into a junction or another reparse point?

Q5. Is OBJ_DONT_REPARSE a supported and documented alternative for this use case?

Q6. If the proposed combination is not officially supported, what alternative API sequence is recommended that preserves all of the following?

Parent-handle-relative directory creation.

Prevention of unintended reparse-point traversal.

Strict collision handling.

Creation-time security descriptor application.

Independent verification of the resulting directory identity.

Q7. Are there any limitations associated with filesystem filter drivers, NTFS reparse points, or specific Windows builds?

4. Requested Engineering Guidance

We would appreciate an authoritative Microsoft API reference, written engineering clarification, or recommendation identifying the supported implementation.

Our objective is to use a documented and maintainable filesystem security design suitable for deployment across customer Windows environments.

We can provide a minimal, non-confidential reproducer if required.

Thank you for your assistance.

Best regards,

Software Development Team