Module open_by_id 

The OpenFileById entry.

Entry 2 of the audited catalogue, and a second open primitive rather than a variant of crate::open::OpenFile. It takes a volume-hint handle and a file identifier instead of a path, and it has no creation disposition at all – it can only open something that already exists. One entry per Win32 call means it is its own entry.

Why a consumer reaches for this

An identifier names a filesystem object, where a path names a location. Reopening by id is structurally incapable of landing on a different object than the one the id already named, while a fresh open against the original path cannot tell a recreated directory from the one a consumer started on. That difference is the whole reason the entry exists.

The volume hint is an input handle, and is owned

This is the first entry to take a handle as an input, so it is the first consumer of CapturedHandle. The hint only needs to name some still-open handle on the same volume as the identifier – it is never itself the object being reopened, so it stays valid even once that object is gone. The request owns a duplicate of it, so the request cannot be left naming a hint its originator has closed.

Structs

OpenFileByIdentifier

An owned, marshalable parameter set for OpenFileById.

Enums

FileIdentifier

Which kind of identifier names the object to open.