Windows Vista defined (hidden) junctions (essentially, symbolic links to directories) to redirect legacy folder paths to their modern paths; e.g, "$HOME/Cookies", "$HOME/My Documents".
The .LinkType property of such paths, as returned by Get-Item / Get-ChildItem should contain string 'Junction', but it is currently $null.
Similarly, the .Target property (the link/junctions's target path) unexpectedly contains $null.
Note that these junctions also have the Hidden and System attributes set (in addition to ReparsePoint).
However, even manually recreating a junction with all these attributes set does not reproduce the problem.
Get-Item -Force $HOME/Cookies | Select Mode, LinkType
Mode LinkType
---- --------
d--hsl Junction
Mode LinkType
---- --------
d--hsl
Note how the LinkType value is missing.
You can verify that the target path is a junction as follows:
cmd /c dir /aL $HOME | sls Cookies
PowerShell Core v6.1.0-preview.3 on Microsoft Windows 10 Pro (64-bit; Version 1709, OS Build:
As far as understand, issue is caused by access rights of this junctions. Them prohibit content enumeration, but PowerShell open them with full read rights and get access denied.
I have 2 PowerShell 5.1 windows open, one returns LinkType and Target and the other doesn't. whoami /all returns the same result, so the Privileges are the same. Both windows are run as Admin.
Get-ChildItem C:\Users\Default -Force -Attributes "Directory+ReparsePoint" -ErrorAction SilentlyContinue | select FullName,LinkType,Target,Attributes
@henrivdr:
It fails consistently for me in PowerShell Core 7.0.0-preview.4 / Windows PowerShell v5.1 and also in Windows PowerShell v5.1.18362.145 on Microsoft Windows 10 1903 (though note that this repo is not for Windows PowerShell).
If @PetSerAl's understanding is correct (which strikes me as likely), then even running as admin should _consistently_ fail.
However, your repro command made me just notice another, presumably closely related problem: see #10630
@mklement0
Noted regarding this repo being for PS Core.
I agree with @PetSerAl, because this works in the window where Get-Chilitem by itself does not work: http://chrisbensen.blogspot.com/2010/06/getfinalpathnamebyhandle.html
So it must be the way the directory is (not) opened with
CreateFile(...CREATION_DISPOSITION_OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS...)
It sill does not make sense why it behaves differently between 2 identical windows.
(The link in your comment has the correct URL, but clicking on it takes you elsewhere.)
It sill does not make sense why it behaves differently between 2 identical windows.
Certainly sounds odd. If you have a reproducible case, please report it on UserVoice and/or here (as a new issue), as applicable.
Here's a proper link
https://stackoverflow.com/questions/16926127/powershell-to-resolve-junction-target-path/16926224#16926224
I am holding on to the window which works, while I implement the C# Add-Type workaround :-)
Stack OverflowIn PowerShell, I need resolve the target path of a junction (symlink). for example, say I have a junction c:\someJunction whose target is c:\temp\target I tried variations of $junc = Get-Item c:\
Solved! I just had to Adjust the process Token Privilege to enable SeBackupPrivilege.
I had to do something similar for another project to take ownership of folders.
https://www.raydbg.com/2017/Token-Privileges-in-PowerShell/
and
https://www.codeproject.com/Articles/21202/Reparse-Points-in-Vista
RayDBG
One common task in my daily work is to create a PowerShell script to modify the ACL(Access Control List) of Folders or Registrys on Windows. When I run some commands to take the ownership of the Folde
What are reparse points, and how do we get their properties.
:tada:This issue was addressed in #10662, which has now been successfully released as v7.0.0-preview.5.:tada:
Handy links:
Most helpful comment
As far as understand, issue is caused by access rights of this junctions. Them prohibit content enumeration, but PowerShell open them with full read rights and get access denied.