JFLarvoire
truename - does not work?
As we can see, this repository's distribution includes a utility for displaying full paths that may be obscured by reparse points — namely, truename.exe. When tested on files and links created using long-established mechanisms like symlinks, junctions, etc., the utility performs as expected.
However, when it comes to AppExecLink, things begin to fall apart.
The utility claims to support this latest Microsoft mechanism for linking, and indeed, for simple executable files — such as pwsh.exe located at:
C:\Users\{username}\AppData\Local\Microsoft\WindowsApps\pwsh.exe
— it correctly resolves the actual target path:
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.5.1.0_x64__8wekyb3d8bbwe\pwsh.exe
So far, so good.
But things get trickier with directories and child objects inside them. In particular, the utility fails completely in such cases.
Take this example:
C:\Users\{username}\AppData\Local\Packages\Microsoft.PowerShell_8wekyb3d8bbwe\LocalCache\Roaming\NuGet\
It contains a single file: nuget.config.
When passed to truename.exe, the utility simply outputs the exact same path:
C:\Users\{username}\AppData\Local\Packages\Microsoft.PowerShell_8wekyb3d8bbwe\LocalCache\Roaming\NuGet\nuget.config
— which strongly suggests that no resolution occurred. It appears the tool just echoed back the input path without interpreting any reparse logic.
After further analysis, it becomes clear why:
The directory LocalCache itself is a reparse point, and crucially, AppExecLink is known to be file-level, not directory-level. This likely explains why truename.exe fails to resolve paths where intermediate components are also reparse points.
Nevertheless, by investigating deeply, we can determine the actual resolved path. It turns out that:
C:\Users\{username}\AppData\Local\Packages\Microsoft.PowerShell_8wekyb3d8bbwe\LocalCache
is internally redirected to:
C:\Users\{username}\AppData
So the full resolved path of the original target is actually:
C:\Users\{username}\AppData\Roaming\NuGet\nuget.config
Hence, the expected correct output of truename.exe for this input:
C:\Users\{username}\AppData\Local\Packages\Microsoft.PowerShell_8wekyb3d8bbwe\LocalCache\Roaming\NuGet\nuget.config
should be:
C:\Users\{username}\AppData\Roaming\NuGet\nuget.config
🔍 Conclusion
The utility truename.exe currently lacks support for resolving such "multi-layer" indirections — i.e., when the input path itself includes intermediate reparse points, and the target object is effectively composed of multiple resolved fragments.
To fully support AppExecLink and similar cases, the tool needs to recursively or contextually resolve all reparse points along the path, not just those on the final object.
