Skip to content

Conversation

@jeffbi
Copy link
Contributor

@jeffbi jeffbi commented May 13, 2017

Brings the Get-ChildItem more in line with the Unix ls -r and the Windows DIR /S native commands. Like these commands the cmdlet will display symbolic links to directories found during recursion but will not recurse into them.

Like the Unix ls command---and unlike the Windows DIR /S command--- the cmdlet will recurse into symlinks given on the command line.

This also will fix the underlying problem behind #3761.

Brings the cmdlet more in line with the Unix "ls -r" and the Windows "DIR /S" commands.

Like the Unix "ls" command, the cmdlet will recurse into symlinks given on the command line, but not into symlinks found during recursion.
@iSazonov
Copy link
Collaborator

@jeffbi Could you please expand "Brings the cmdlet more in line with the Unix ls -r and the Windows DIR /S commands" for future docs (describe a behavior of the native commands)?

@jeffbi
Copy link
Contributor Author

jeffbi commented May 13, 2017

@iSazonov Updated the description.

{
Dir(recursiveDirectory, recurse, depth - 1, nameOnly, returnContainers);
bool hidden = false;
if (!Force) hidden = (recursiveDirectory.Attributes & FileAttributes.Hidden) != 0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use pattern:

if ( ... )
{
    ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@iSazonov This all-on-one-line pattern, which I don't like either, is used in a couple of places in the code. Shall I change them all?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General rule - do not make changes that do not belong to the main remedy in order not to complicate the review.
But maintainers may request/allow to correct bad patterns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks.

Fixed

@iSazonov
Copy link
Collaborator

@jeffbi Thanks for the good fix!

LGTM.

@jeffbi
Copy link
Contributor Author

jeffbi commented May 15, 2017

@iSazonov Thanks for the review!

// if "Hidden" is explicitly specified anywhere in the attribute filter, then override
// default hidden attribute filter.
if (Force || !hidden || isFilterHiddenSpecified || isSwitchFilterHiddenSpecified)
if (!InternalSymbolicLinkLinkCodeMethods.IsReparsePoint(recursiveDirectory))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jeffbi Could you please summarize the description and add it as comments right before this statement? I hope the comment can explain why we are checking IsReparsePoint on recursiveDirectory and what behavior of Get-ChildItem we are trying to get by having this check. I'm sure the comments will be very helpful to other people when looking at this code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments added.

$ci[1].Name | Should MatchExactly $filenamePattern
$ci[2].Name | Should MatchExactly $filenamePattern
}
It "Get-ChildItem does not recurse into symbolic links" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test case title is a little confusing because Get-ChildItem $alphaLink -Recurse works recursively as expected :)
Maybe the following is better?
Get-ChildItem does not recurse into symbolic links unless it's explicitly specified on command line

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Title changed.

@daxian-dbw
Copy link
Member

Great fix @jeffbi! This will fix #3761, right?

@daxian-dbw daxian-dbw self-assigned this May 15, 2017
@jeffbi
Copy link
Contributor Author

jeffbi commented May 15, 2017

@daxian-dbw Yes, this prevents the situation that drives #3761.

@daxian-dbw
Copy link
Member

Somehow the AppVeyor CI status is not reported back to Github, but the AppVeyor CI build was successful:
https://ci.appveyor.com/project/PowerShell/powershell/build/6.0.0-beta.1-3181. Given that, I will merge this PR.

@daxian-dbw daxian-dbw merged commit ee1a897 into PowerShell:master May 15, 2017
@jeffbi jeffbi deleted the child-item-1875 branch May 15, 2017 21:45
@SteveL-MSFT SteveL-MSFT added the Breaking-Change breaking change that may affect users label May 31, 2017
@mklement0
Copy link
Contributor

I think we need the ability to opt in with respect to symlink recursion - please see #3951

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Breaking-Change breaking change that may affect users

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants