Request for clarification: NtCreateFile relative opens, reparse-point safety, and metadata-only access

Question

Request for clarification: NtCreateFile relative opens, reparse-point safety, and metadata-only access

luan jeanne 0

We are designing a read-only Windows metadata collector that must inspect a small, explicitly allowlisted set of files and directories without following unexpected reparse points or reading file contents.

We need authoritative clarification of the supported Windows API contract, rather than relying on observed behavior on an individual machine.

1. Proposed operation

The proposed operation uses:

NtCreateFile

A previously opened parent directory handle supplied through OBJECT_ATTRIBUTES.RootDirectory

A single-component relative ObjectName (no path separators)

CreateDisposition = FILE_OPEN

CreateOptions including FILE_OPEN_REPARSE_POINT

No FILE_DIRECTORY_FILE or FILE_NON_DIRECTORY_FILE flag, so the final object type can be inspected after opening

Metadata-only access, such as FILE_READ_ATTRIBUTES and, where necessary, READ_CONTROL

The returned handle would then be inspected using handle-based metadata APIs. The collector would not enumerate directories, read file contents, or modify the object.

2. Questions requiring authoritative clarification

Is this type-neutral NtCreateFile combination officially supported for both files and directories on currently supported Windows versions and NTFS?

Does FILE_OPEN_REPARSE_POINT guarantee that the final component is opened as the reparse-point object itself rather than following its target, including when the final component is a directory?

What guarantees apply when RootDirectory references an already-open directory handle, but another process concurrently changes that directory's reparse-point state?

Is the relative open guaranteed to remain bound to the same directory object throughout name resolution, or can concurrent reparse-point changes produce behavior that is not defined by the public API contract?

Does FILE_OPEN_NO_RECALL guarantee that the operation will not trigger file hydration, Cloud Files provider callbacks, network activity, or other external effects? If not, which documented API or flags provide such a guarantee?

Are there documented restrictions or supported combinations involving FILE_OPEN_REPARSE_POINT, FILE_DIRECTORY_FILE, FILE_NON_DIRECTORY_FILE, and FILE_OPEN_NO_RECALL?

If this design cannot provide the required guarantees, what supported Windows API pattern should be used instead?

3. Required environment clarification

Please identify any differences relevant to:

Supported Windows builds

NTFS and ReFS

Cloud Files placeholders

Third-party file-system minifilters

Reparse-point types

Concurrent directory changes

4. Security requirement

The required guarantee is that the collector must not silently access an unintended object or trigger unapproved file-content access or external side effects.

If Windows cannot provide this guarantee through the proposed operation, we need that limitation stated explicitly so that the design can fail closed.

We are not requesting a general statement that the API exists. We need the precise documented behavioral and concurrency guarantees, including unsupported combinations and limitations.

Request for clarification: NtCreateFile relative opens, reparse-point safety, and metadata-only access

We are designing a read-only Windows metadata collector that must inspect a small, explicitly allowlisted set of files and directories without following unexpected reparse points or reading file contents.

We need authoritative clarification of the supported Windows API contract, rather than relying on observed behavior on an individual machine.

1. Proposed operation

The proposed operation uses:

NtCreateFile

A previously opened parent directory handle supplied through OBJECT_ATTRIBUTES.RootDirectory

A single-component relative ObjectName (no path separators)

CreateDisposition = FILE_OPEN

CreateOptions including FILE_OPEN_REPARSE_POINT

No FILE_DIRECTORY_FILE or FILE_NON_DIRECTORY_FILE flag, so the final object type can be inspected after opening

Metadata-only access, such as FILE_READ_ATTRIBUTES and, where necessary, READ_CONTROL

The returned handle would then be inspected using handle-based metadata APIs. The collector would not enumerate directories, read file contents, or modify the object.

2. Questions requiring authoritative clarification

Is this type-neutral NtCreateFile combination officially supported for both files and directories on currently supported Windows versions and NTFS?

Does FILE_OPEN_REPARSE_POINT guarantee that the final component is opened as the reparse-point object itself rather than following its target, including when the final component is a directory?

What guarantees apply when RootDirectory references an already-open directory handle, but another process concurrently changes that directory's reparse-point state?

Is the relative open guaranteed to remain bound to the same directory object throughout name resolution, or can concurrent reparse-point changes produce behavior that is not defined by the public API contract?

Does FILE_OPEN_NO_RECALL guarantee that the operation will not trigger file hydration, Cloud Files provider callbacks, network activity, or other external effects? If not, which documented API or flags provide such a guarantee?

Are there documented restrictions or supported combinations involving FILE_OPEN_REPARSE_POINT, FILE_DIRECTORY_FILE, FILE_NON_DIRECTORY_FILE, and FILE_OPEN_NO_RECALL?

If this design cannot provide the required guarantees, what supported Windows API pattern should be used instead?

3. Required environment clarification

Please identify any differences relevant to:

Supported Windows builds

NTFS and ReFS

Cloud Files placeholders

Third-party file-system minifilters

Reparse-point types

Concurrent directory changes

4. Security requirement

The required guarantee is that the collector must not silently access an unintended object or trigger unapproved file-content access or external side effects.

If Windows cannot provide this guarantee through the proposed operation, we need that limitation stated explicitly so that the design can fail closed.

We are not requesting a general statement that the API exists. We need the precise documented behavioral and concurrency guarantees, including unsupported combinations and limitations.

0 comments

1 answer

Your answer

Answer 1

NtCreateFile with the proposed flags cannot be treated as providing the absolute fail-closed guarantee: the public contract does not define an atomic object-or-refusal boundary against concurrent reparse changes, and FILE_OPEN_NO_RECALL does not promise callback-free, network-free, or side-effect-free inspection.

Documented behavior

A non-null OBJECT_ATTRIBUTES.RootDirectory makes ObjectName relative to the directory represented by that handle. A single-component name is therefore a valid relative name.^1^
FILE_OPEN opens an existing object and fails if it does not exist.^2^
If FILE_OPEN_REPARSE_POINT is specified and the object being opened has a reparse point, normal reparse processing does not occur; NtCreateFile attempts to open the reparse-point object directly. Without the flag, normal reparse processing occurs.^1^
Reparse points can exist on files or directories. Their behavior may be supplied by a filesystem filter identified by the reparse tag.^3^

That supports using FILE_OPEN_REPARSE_POINT to suppress normal processing of the final reparse-point object, including a directory object. It does not document that:

Every earlier component used to acquire RootDirectory was opened without traversal.
A concurrent change to the held directory’s reparse state must produce either the original object or failure.
A filesystem or minifilter cannot perform other processing during the create.
The open has no observable external effect.

The documentation says what a relative name means, but does not specify an atomic boundary between relative lookup and a concurrent set, delete, replacement, or modification of a reparse point. The closely matching Q&A determination likewise concludes that the published contract does not establish the requested object-or-refusal guarantee; it is corroboration of the documentation gap, not a normative API specification.^4^

Option compatibility

Omitting both type-selection flags is not expressly prohibited. However, the documentation does not promise that every filesystem, filter, reparse tag, and Windows-version combination will accept the resulting type-neutral request.

There is an important documented restriction if FILE_DIRECTORY_FILE is added: its compatible-options list contains only the synchronous flags, FILE_WRITE_THROUGH, FILE_OPEN_FOR_BACKUP_INTENT, and FILE_OPEN_BY_FILE_ID. It does not list FILE_OPEN_REPARSE_POINT or FILE_OPEN_NO_RECALL.^2^ Consequently, the public documentation does not establish that either combination with FILE_DIRECTORY_FILE is supported.

FILE_NON_DIRECTORY_FILE requires the opened object not to be a directory. It is unsuitable for a type-neutral collector.

Requesting FILE_READ_ATTRIBUTES, plus READ_CONTROL only when the security descriptor is needed, avoids requesting file-data access. Do not use generic access masks: the documented generic-read mapping includes FILE_READ_DATA.^2^

Recall and Cloud Files

FILE_OPEN_NO_RECALL is documented only as an instruction to filters that perform offline storage or virtualization not to recall file contents because of the open.^2^ It is not documented as guaranteeing:

no filter or Cloud Files callback;
no provider communication or network activity;
no metadata retrieval;
no external side effect;
compliance by every third-party filter.

For an already-open Cloud Files placeholder, CfGetPlaceholderInfo is the purpose-built metadata query. It requires only READ_ATTRIBUTES and does not modify the placeholder, but it still requires acquiring a handle first and does not document the open itself as callback-free or network-free.^5^

Cloud Files reparse points may also be hidden from ordinary applications unless placeholder-compatibility mode is changed, so treating all visible reparse behavior as uniform is unsafe.^6^

Filesystem and filter scope

NTFS and ReFS support reparse points; that fact does not establish identical race or filter behavior.^7^
Behavior can depend on the reparse tag and its associated Microsoft or third-party filter.
No cited public contract supplies the required universal guarantee across supported builds, NTFS, ReFS, Cloud Files placeholders, arbitrary reparse tags, and third-party minifilters.

Safe design conclusion

For the stated security requirement, fail closed before issuing the open whenever unapproved open-time callbacks or external activity are unacceptable. Post-open checks—such as handle-based attributes and identity, FSCTL_GET_REPARSE_POINT, and CfGetPlaceholderInfo for confirmed placeholders—can detect mismatches but cannot undo effects that occurred while opening. FSCTL_GET_REPARSE_POINT is the documented operation for retrieving reparse data.^8^

No cited public user-mode API documents a universal callback-free, network-free, race-atomic metadata acquisition mechanism satisfying all these conditions. If the environment cannot be constrained to trusted filesystems, filters, providers, and mutation controls, there is no documented basis for accepting the operation as secure.

For a binding determination, open an official Windows developer support incident or use the organization’s Microsoft support agreement. Request a written, scope-qualified answer covering the exact NtCreateFile parameters, Windows builds, NTFS and ReFS, Cloud Files versions, reparse tags, installed minifilters, and concurrent mutation scenarios. Microsoft Q&A results and machine testing should not be treated as extending the published API contract.

References