Powershell: Get-ChildItem will recurse indefinititely for recursive symlinks

[DHowett]

Steps to reproduce

gci -r /sys

Expected behavior

gci reaches its terminus, and then ceases

Actual behavior

Because of these recursive symlinks,

PS /> ls -la /sys/bus/cpu/devices/cpu0/
lrwxrwxrwx.  1 root root    0 Aug 18 16:12 node0 -> ../../node/node0
PS /> ls -la /sys/bus/cpu/devices/cpu0/node0/
lrwxrwxrwx. 1 root root    0 Aug 18 16:12 cpu0 -> ../../cpu/cpu0

gci eventually runs into something like this:

    Directory: /sys/bus/cpu/devices/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/nod
    e0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0/node0/cpu0


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----       08/18/2016     16:13                cache

It has shown no sign of stopping.

Linux's equivalent ls -lR /sys will cease, as it will not descend into already visited nodes.

Environment data

Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.9
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[andschwa]

This is being resolved in #2252.

[DHowett-MSFT]

Alas, #2252's description contains

Does not fix more complicated symlink loops, as in sys.

[mklement0]

Beta.2 made this issue go away for now, because #3780 _categorically_ prevents following directory symlinks, but, given that this ability should be available on an _opt-in_ basis, this issue may need a proper fix after all - see #3951.

[iSazonov]

@mklement0 Do you continue? Leave you as assignee?

[mklement0]

Given that @jeffbi, the current assignee, has already done work in this area, I think he's the better choice, if he's up for it.

We should also get buy-in for #3951 first (I do believe it's an essential feature) - or is the fact of it being labeled "Issue-Enhancement" by @SteveL-MSFT an indication that the team agrees it should be done?

[iSazonov]

@mklement0 Ask about the approve there :-)

[jeffbi]

I'm happy to continue working on this once the desired behavior is defined, including the mechanism for opting in.

[SteveL-MSFT]

@mklement0 Issue-Enhancement doesn't imply it must be done (for 6.0.0 anyways), just that it's a new capability (since we were ok with the breaking change, that becomes the norm)

[mklement0]

Thanks, @SteveL-MSFT.

Generally, what is it that tells us whether something will be implemented?

[iSazonov]

"Won't fix" label is " will be NOT implemented" 😄

[SteveL-MSFT]

@mklement0 the only way to determine if there is a good chance that something will be implemented is that it's assigned to someone. for the 6.0.0 release anything with a 6.0.0-highpriority means we've triaged it and believe it's a must have before we can declare a 6.0.0 release candidate, the other 6.0.0-* milestones are ones we use internally for triage purposes and don't imply will be fixed. if there's any issue you believe is must have for 6.0.0 (rather than a release after 6.0.0), call my attention to it (also good to include @joeyaiello). thanks!

[rjmholt]

Given that #4020 is merged, is this still an issue?

[SteveL-MSFT]

Did a simple test of creating a symlink within a folder to itself and across two different folders and it doesn't recurse infinitely