Expand description
The GetFinalPathNameByHandleW entry.
Entry 7 of the audited catalogue, and the one with the strongest offload
evidence. Globazog reaches it through std::fs::canonicalize, which it
performs on its submitting thread once per root – a full CreateFileW
plus this call plus CloseHandle, with unbounded latency on a network path
– and repeats per reparse-point candidate on a worker. It is first-class
here, not second-tier.
§The call reports a length, and the caller grows the buffer
Unlike crate::query, this call does report a length – but with a
twist that is easy to get wrong. On success it returns the number of
characters written, excluding the terminating NUL. When the buffer is
too small it returns the size required including the NUL, and does not
set a failure code the caller would recognise as “try again bigger”. The
two returns are distinguished by comparing against the buffer size, and this
entry does that retry itself rather than handing a caller a raw length it
must interpret.
The retry is bounded. A path cannot grow without limit between attempts, so
an unbounded loop could only spin on a pathological or hostile filesystem;
FinalPathError::Unstable reports that rather than hanging a worker.
Structs§
- Final
Path Flags - Which form of the final path to report.
- Query
Final Path - An owned, marshalable parameter set for
GetFinalPathNameByHandleW.
Enums§
- Final
Path Error - Why a final path could not be resolved.