Is NtCreateFile with FILE_OPEN_REPARSE_POINT supported for relative directory opens on Windows 11?

Hi @Turn U- ,

Thank you for the clearly scoped question, and for separating the initial trusted handle, concurrency protection, and authorization from this one. I'll keep this answer focused on what the published documentation establishes for this configuration and how that maps to your design.

1. Opening an existing directory with this combination

The user-mode NtCreateFile (winternl.h) documentation describes the function as able to open an existing file or directory, lists zero or OBJ_CASE_INSENSITIVE as the valid Attributes values, and does not restrict FILE_READ_ATTRIBUTES for directories (only FILE_READ_DATA, FILE_WRITE_DATA, FILE_APPEND_DATA, and FILE_EXECUTE are called out as not to be used). So the individual parameters you chose are consistent with the documentation.

Omitting FILE_DIRECTORY_FILE also lines up with the documentation, because the list of CreateOptions flags compatible with FILE_DIRECTORY_FILE does not include FILE_OPEN_REPARSE_POINT. The consequence is that the call itself does not enforce that the target is a directory. Since your handle has FILE_READ_ATTRIBUTES, the recommended approach is to read the attributes on the returned handle and confirm the object is a directory before continuing.

2. Reparse point behavior on the final component

The documentation states that when FILE_OPEN_REPARSE_POINT is specified and the file being opened has a reparse point, normal reparse processing does not occur and NtCreateFile attempts to directly open the reparse point file. Mounted folders and symbolic links are implemented as reparse points, identified by the IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK tags (Determining Whether a Directory Is a Mounted Folder), so they fall under this behavior. Based on this, the expected result is that the handle refers to the reparse point itself rather than its target. CreateFile documents the same outcome explicitly for symbolic links with FILE_FLAG_OPEN_REPARSE_POINT.

For your inspection logic, this means that once you see FILE_ATTRIBUTE_REPARSE_POINT on the opened component, you can check the reparse tag (the linked article shows how to read it and compare it against values such as IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK) and decide how your tool should treat that entry, instead of relying on the open to classify it for you.

3. Reusing the handle as RootDirectory

This is directly documented: RootDirectory can be a handle to a directory obtained by a preceding call to NtCreateFile, and ObjectName is then interpreted relative to that directory. So chaining single-component opens from a directory handle matches the documented model.

The documentation describes this in terms of a directory handle. It does not describe using a handle that was opened on a reparse point itself, such as a junction opened with FILE_OPEN_REPARSE_POINT, as RootDirectory. Based on that, the safest design is to use a handle as the next RootDirectory only after confirming it is a directory without the reparse point attribute, and to handle reparse point entries separately as described in point 2.

4. Qualifications

Reparse Points and File Operations notes that reparse point behavior depends on the specific implementation and its associated file system filter. That means third-party reparse implementations and filter drivers are part of the environment your tool needs to account for. The driver-side NtCreateFile (ntifs.h) reference also shows that file system behavior can change between versions (for example, the Windows 11 version 24H2 NTFS change for FILE_NON_DIRECTORY_FILE). For offline or virtualized files, the same reference documents FILE_OPEN_NO_RECALL, which instructs filters that perform offline storage or virtualization not to recall file contents as a result of the open. This is relevant if you want to avoid side effects during metadata-only opens.

5. Normative documentation or support statement

To state it explicitly as you asked: the published documentation covers the individual pieces above (relative opens through RootDirectory, the general FILE_OPEN_REPARSE_POINT behavior, and reuse of an NtCreateFile directory handle as RootDirectory). It does not provide a single normative guarantee for this exact combination across all Windows versions, file systems, and filter drivers. If you need a formal support statement at that level, opening a case with Microsoft Support would be the appropriate path.

I hope this helps clarify how the documentation applies to your design.

If you found this helpful, you can refer to this guidance to confirm it and help others with similar questions.

Thank you.