raandree / NTFSSecurity

Managing permissions with PowerShell is only a bit easier than in VBS or the command line as there are no cmdlets for most day-to-day tasks like getting a permission report or adding permission to an item. PowerShell only offers Get-Acl and Set-Acl but everything in between getting and setting the ACL is missing. This module closes the gap.
MIT License
431 stars 61 forks source link

Set-NTFSOwner with a filesystem object as a positional parameter #88

Open incansvl opened 4 weeks ago

incansvl commented 4 weeks ago

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 FullNameaccording 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?