Tree: 9783d2af4d

master

4.2.6

4.2.4

4.2.3

5.0.0-rc9

5.0.0-rc8

5.0.0-rc7

5.0.0-rc6

5.0.0-rc5

5.0.0-rc4

5.0.0-rc3

5.0.0-rc2

5.0.0-rc1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from '9783d2af4d'

${ noResults }

Commit Graph

3 Commits (9783d2af4d6a1ef364b13e57e707e0b05a5f0971)

Author	SHA1	Message	Date
Raimund Andree	9783d2af4d	fix(access,audit): keep the scope of a piped object from reaching the next one Independent review of 93ed2c7: ProcessRecord of Add-NTFSAccess, Remove-NTFSAccess, Add-NTFSAudit, and Remove-NTFSAudit wrote the scope that it converts from AppliesTo into the fields behind InheritanceFlags and PropagationFlags. PowerShell resets only the parameters that the previous piped object bound, so the next object that had no scope, or only one flag, took the scope of the one before it: AppliesTo ThisFolderOnly, then none gave None/None twice, and Remove left the InheritOnly part of every entry. Without the default set (93ed2c7) a piped path object with AppliesTo reaches that code; for a piped -SecurityDescriptor object it was a defect of rc7 already. The flags of a record are locals now. The loop of the two Remove cmdlets converted the scope a second time into the same fields; the locals make that redundant, so it is gone. The tests pipe objects with and without a scope, a CSV file, and descriptor objects into the four cmdlets: red on the build of 93ed2c7 (8 of 87 cases of the two files, in every elevated configuration; 4 in the basic-user ones, where the audit rows skip), green on this build. An empty AppliesTo cell fails to bind for that row only; a test pins it. The Remove-NTFSAudit PathSimple row cannot tell the sets apart (its entry is on a file), and its comment says so. Docs/Examples.md no longer says that a scope is needed so that PowerShell can choose the parameter set (true before 5.0.0 only); the changelog entry names the new errors. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>	3 weeks ago
Raimund Andree	93ed2c7da4	fix(access,audit): bind the AppliesTo property of a piped object for paths Add-NTFSAccess, Remove-NTFSAccess, Add-NTFSAudit, and Remove-NTFSAudit declared PathComplex as the default parameter set. An object that had Path, Account, and AccessRights satisfied the mandatory parameters of the default set, so PowerShell never tried PathSimple and the cmdlet dropped the AppliesTo property of the object. Since 4b1abc9 made -AppliesTo mandatory in the Simple sets, the default set is redundant for every call that names its parameters, and it masked PathSimple for the pipeline. Without a default set, an object that has AppliesTo binds PathSimple, one that has InheritanceFlags or PropagationFlags binds PathComplex, and one that has neither binds PathComplex with the default scope. An object that has AppliesTo and InheritanceFlags now fails with AmbiguousParameterSet, like the same two named parameters. Named calls, -SecurityDescriptor calls without AppliesTo, and the round trip Get-NTFSAccess | Add-NTFSAccess keep their behavior. The tests pipe objects of each shape and fail without the change. The cmdlet pages and the help file follow the build. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>	3 weeks ago
Raimund Andree	ef45b388c7	test(access): assert the parameter sets that the judged matrix found untested Adds Tests/ParameterSets.Access.Tests.ps1, closing the TestNeeded rows of paramsets/judged-access.csv for Add-NTFSAccess, Remove-NTFSAccess, Clear-NTFSAccess, Get-NTFSAccess, Get-NTFSOrphanedAccess, Get-NTFSSimpleAccess, and Get-NTFSEffectiveAccess: 20 new It blocks (26 executed cases) covering pipeline binding (ValueFromPipeline and ValueFromPipelineByPropertyName, including positional file/folder objects), -PassThru combined with one denied and one succeeding path, error ErrorId/category/target for read and write failures, continuation after a per-item error, state read back with .NET (not -PassThru/Get-NTFSAccess), SecurityDescriptor-set pipelines and memory-vs-disk behavior, and the declared output types and PathSimple/SDSimple vs PathComplex/SDComplex parameter-set boundaries. No row with GapKind=MaintainerDecision is pinned: the -SecurityDescriptor sets of Add/Remove keep their open per-item error behavior untested either way. Finding: a plain piped object with an AppliesTo property does not steer Add-NTFSAccess/Remove-NTFSAccess to the PathSimple/SDSimple parameter set by itself; PowerShell resolves the ambiguity to the default set (PathComplex/ SDComplex) and silently drops the unmatched property. The proposed test for that exact shape (notes section (b), item 2c) could not be written as specified; the pipeline test for PathSimple instead binds -Path through the pipeline while -AppliesTo is named explicitly, which does select the set. Validated in all four configurations (elevated/basic user, Windows PowerShell 5.1/PowerShell 7): 26 passed, 0 failed, 0 skipped in each. Eight one-statement production mutations across all seven cmdlets were applied in an isolated worktree, built, and run against this file; each was detected by at least one new test, then the source was restored exactly and rebuilt. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant <ai@example.com>	3 weeks ago