Expand description
The GetFullPathNameW entry.
Entry 9 of the audited catalogue, and the only one that takes neither a handle nor produces one.
§What it solves, and what it leaves standing
This call is lexical. It resolves relative components and ./..
against the process current directory, and it touches no filesystem: it will
happily resolve a path to something that does not exist.
So it solves exactly one problem – the process current directory is shared mutable state that any thread can change, so a relative path means something different depending on when it is resolved. Performing this on the submitting thread pins that meaning.
It does not solve the session-relative drive-letter hazard, and saying
so plainly matters more than the part it does solve. GetFullPathNameW
never expands a drive letter, and a drive letter is resolved against the
logon session of whatever token is in effect at open time. A path resolved
here and opened on a worker under a captured token from another logon
session can still name a different device. That hazard is open at the
workspace level; this entry inherits it and does not close it.
A consumer that wants the final, filesystem-verified path of an object
wants crate::final_path, which requires a handle and therefore an open.
Structs§
- Resolve
Full Path - An owned, marshalable parameter set for
GetFullPathNameW.
Enums§
- Full
Path Error - Why a full path could not be resolved.