Is OBJ_DONT_REPARSE supported by user-mode NtCreateFile with a directory-relative name?

Question

Is OBJ_DONT_REPARSE supported by user-mode NtCreateFile with a directory-relative name?

Chris Terrell 0

This brief concerns published API contracts for an initial file acquisition before content inspection. It requests clarification of documentation, without asserting anything about a particular host.

The proposed inspection requires an independently established relationship between an eligible subject, permitted metadata resolution, and the object reached. Opening and querying are access operations. Legitimate supply, access eligibility and a trusted starting object remain separate prerequisites.

The documentation basis is the retained official material retrieved on 2026-09-13 UTC / September 12 Central. Quoted phrases below are direct excerpts; other descriptions are paraphrases. The question below is a proposed inquiry.

The NtCreateFile Parameters → ObjectAttributes.Attributes description says: “This value can be zero or OBJ_CASE_INSENSITIVE.” The general OBJECT_ATTRIBUTES Members → Attributes description says OBJ_DONT_REPARSE means “no reparse points will be followed when parsing the name of the associated object.” NtCreateFile, OBJECT_ATTRIBUTES

For user-mode NrCreateFIle, with an existing directory handle as RootDirectory and one relative component as ObjectName, is OBJ_DONT_REPARSE supported? How should these descriptions be reconciled? Please identify the applicable published contract, refusal scope and platform conditions.

An affirmative answer would not establish legitimate subject supply, an eligible starting object, environmental conditions or authorization to acquire anything. Nor would it establish that a native-acquired handle satisfies ReOpenFile’s requirements or completes a reader method. The intended later observation compares two returned byte sequences; it does not claim snapshot semantics or continuous immutability.

Please identify the applicable published sections or any unresolved documentation discrepancy. No particular implementation or favorable answer is presumed.

0 comments

1 answer

Your answer

Answer 1

The published contract in the provided material does not state that user-mode NtCreateFile supports OBJ_DONT_REPARSE for a directory-relative name, and it does not define any special behavior for that combination.

The applicable published sections show a documentation mismatch:

The NtCreateFile parameter description for ObjectAttributes.Attributes says the value “can be zero or OBJ_CASE_INSENSITIVE.”
The general OBJECT_ATTRIBUTES structure definition lists additional flags, including OBJ_DONT_REPARSE, and defines it as preventing reparse points from being followed while parsing the object name, returning STATUS_REPARSE_POINT_ENCOUNTERED if a reparse is encountered.

For directory-relative naming, the published NtCreateFile contract does support relative resolution in general:

If RootDirectory is non-NULL, ObjectName specifies a file name relative to that directory.
The file name can therefore be supplied as a relative name against an existing directory handle.

What is not published in the provided material is any NtCreateFile-specific statement that:

OBJ_DONT_REPARSE is accepted by user-mode NtCreateFile
OBJ_DONT_REPARSE is rejected by user-mode NtCreateFile
support differs between fully qualified and directory-relative names
support depends on a particular platform version, file system, or other runtime condition for this API contract

So, based on the published material provided, the reconciled reading is:

The general OBJECT_ATTRIBUTES documentation defines OBJ_DONT_REPARSE as a valid structure flag with specific semantics.
The NtCreateFile page narrows its own ObjectAttributes.Attributes description to “zero or OBJ_CASE_INSENSITIVE” and does not mention OBJ_DONT_REPARSE.
That leaves an unresolved documentation discrepancy for NtCreateFile, including the directory-relative case.

The refusal scope and platform conditions are also not defined in the provided material. The only published failure behavior tied to OBJ_DONT_REPARSE in the provided context is the general statement that reparses cause failure with STATUS_REPARSE_POINT_ENCOUNTERED when that flag is set. No narrower user-mode NtCreateFile contract is published here for relative names.