You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Set-NTFSOwner works on files or directories (file system objects), and has the file path as the first parameter. This parameter is an alias of FullName according to the docs (Set-NTFSOwner), so I assumed it would automatially pick up the FullName property of an object that was passed to that parameter.
I was surprised to find that in a typical Powershell loop across a file tree-
$FileTree = Get-Childitem $Root -Recurse -Force
foreach ($Item in $FileTree) {
# Items not owned by the expected user
if ($Item.Owner -ne 'localmachine\localuser') {
Set-NTFSOwner $Item -Account 'localmachine\localuser'
}
}
this fails with the error Set-NTFSOwner : Unable to find the specified file.
It is fixable by changing key line to-
Set-NTFSOwner $Item.FullName -Account 'localmachine\localuser'
or- Set-NTFSOwner -Path $Item.FullName -Account 'localmachine\localuser'
Perhaps Set-NTFSOwner is trying to access the relative filename rather than the full path to the file?
I don't think this is consistent with the majority of built-in Powershell cmdlets that operate on files, that seem happy to accept a filesystem object or a full file path for a Path paramater, and do the right thing with either.
Is this behaviour consistent across all the NTFSSecurity cmdlets, or is Set-NTFSOwner differnt in this regard?
The text was updated successfully, but these errors were encountered:
Set-NTFSOwner
works on files or directories (file system objects), and has the file path as the first parameter. This parameter is an alias ofFullName
according to the docs (Set-NTFSOwner), so I assumed it would automatially pick up the FullName property of an object that was passed to that parameter.I was surprised to find that in a typical Powershell loop across a file tree-
this fails with the error Set-NTFSOwner : Unable to find the specified file.
It is fixable by changing key line to-
Set-NTFSOwner $Item.FullName -Account 'localmachine\localuser'
or-
Set-NTFSOwner -Path $Item.FullName -Account 'localmachine\localuser'
Perhaps Set-NTFSOwner is trying to access the relative filename rather than the full path to the file?
I don't think this is consistent with the majority of built-in Powershell cmdlets that operate on files, that seem happy to accept a filesystem object or a full file path for a
Path
paramater, and do the right thing with either.Is this behaviour consistent across all the NTFSSecurity cmdlets, or is
Set-NTFSOwner
differnt in this regard?The text was updated successfully, but these errors were encountered: