Enable Get-ChildItem to produce Mode property even if cannot determine if hardlink - #7355
Conversation
… not to be defined
0d6d779 to
5943c51
Compare
|
Steve Lee (@SteveL-MSFT) What will be the output after this change, will it exclude such files ? |
|
PRASOON KARUNAN V (@kvprasoon) no. With this change, it should work the same as with Windows PowerShell before we added the check for hard links. |
|
PRASOON KARUNAN V (@kvprasoon) It will not exclude such files. The mode for such files will not have |
|
Dongbo Wang (@daxian-dbw) Thanks for the clarification. |
Ilya (iSazonov)
left a comment
Ilya (iSazonov)
left a comment
There was a problem hiding this comment.
LGTM with one minor comment.
| } | ||
| } | ||
|
|
||
| return false; |
There was a problem hiding this comment.
We could remove if-s:
bool succeeded = InternalSymbolicLinkLinkCodeMethods.GetFileInformationByHandle(handle, out handleInfo);
return succeeded && (handleInfo.NumberOfLinks > 1);There was a problem hiding this comment.
Good suggestion. Will update.
|
Dongbo Wang (@daxian-dbw) FYI, I had to go back to the PR to figure this one out. The message used to commit wasn't as good as the PR title |
… unable to determine (PowerShell#7355)
6 participants
PR Summary
Some files in the user directory on Windows such as 'NTUSER.DAT' cause the IsHardLink() check to fail with an INVALID_HANDLE win32 error. This causes the
Modeproperty to fail being defined even though it was fine up until that last api call. I don't see any reason to throw an exception if the hard link check fails, instead just return false since we cannot determine it's a hardlink.Fix #7353
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests