The cmdlet page and the CHANGELOG said that Get-NTFSEffectiveAccess warns
that the result is based on this computer only when it returns a result. With
-ExcludeNoneAccessEntries, the cmdlet warns for an account without access and
returns nothing for it, so the text now says when it calculated a result. The
help file is regenerated with platyPS 0.14.2 and differs by that paragraph.
The tests of the documentation, the help, the wiki, the release, and the
manifest pass in Windows PowerShell 5.1 and PowerShell 7, as an administrator
and as a basic user.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Get-NTFSHardLink and New-NTFSHardLink -PassThru combine the root of the path
that the caller gives with names that Windows reports relative to the root of
the real volume. When the two roots differ, such as for a drive that subst
made, Get-NTFSHardLink writes a FileNotFound error for a file that exists, and
New-NTFSHardLink -PassThru creates the link and then stops with a terminating
FileNotFoundException, so the links that follow in the pipeline aren't
created. The real path, and New-NTFSHardLink without -PassThru, work.
A fix needs the real volume root of the file and a decision about the names
that a mount point returns, which changes the output of two cmdlets. The cmdlet
pages and the CHANGELOG state the limit instead. A volume that is mounted into
a folder, and a junction or symbolic link to another volume, were not run and
are called probable.
Checked in Windows PowerShell 5.1 and PowerShell 7 with a substituted drive:
the five claims of the pages hold in both editions. The help file is
regenerated with platyPS 0.14.2 and differs by the two new paragraphs.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Get-NTFSEffectiveAccess returned no access and no error when Windows refused
to start the authorization manager for the computer of -ServerName.
Win32.GetEffectiveAccess ignored what the initialization threw (an outer
catch { }), so the result looked like an account without any rights. It
reproduces on Windows Server 2025 in both editions with a name of 32,718
characters or more, which fails with error 14, where a shorter name gets RPC
server unavailable and falls back to this computer.
One try/catch now records every exception, and the cmdlet writes a
GetEffectiveAccessError. The warning that the result is based on this computer
comes only with a result now: it also preceded an error, such as for an
account that Windows can't resolve when the computer can't be reached, which
the cmdlet page and the lab tests contradict.
Two tests failed first in Windows PowerShell 5.1 and PowerShell 7, as an
administrator and as a basic user, and pass in all four configurations. The
cmdlet page, the help file, and the CHANGELOG say what changed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The follow-up review of 7bc7925 probed the sentence "an AppliesTo that is an
empty string or not the name of a scope is ignored, and the object gets the
default scope" and found it too narrow. What the cmdlets do, in both
editions, on the package of 9783d2a and on the package before the fix
(probe p-unconvertible-appliesto.ps1):
- A value that PowerShell cannot convert to a scope, such as the empty cell
of a CSV file or a misspelled name, is ignored, and the object is handled
as one without AppliesTo: it uses its own InheritanceFlags and
PropagationFlags, or the default scope when it has none. This is the same
before and after the fix.
- A row of a CSV file with fewer fields than its header gives $null, and a
$null AppliesTo fails to bind for that object.
- An object that has both Path and SecurityDescriptor now fails with
AmbiguousParameterSet; before, the path won and the descriptor was
ignored. No cmdlet of the module produces such an object.
The changelog entry, the four cmdlet pages, and the help file say so.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The follow-up review of 9783d2a found that "an empty AppliesTo fails to
bind", in the changelog entry and in the four cmdlet pages, holds only for
$null. A blank cell that Import-Csv reads is an empty string, which the
binder cannot convert: PathSimple does not bind, and the row gets the
default scope, as an object without the property does. An AppliesTo that
is not the name of a scope is ignored the same way (probe
p-empty-appliesto.ps1, both editions, on the package of 9783d2a and on
the baseline). Only $null fails to bind, with
ParameterArgumentValidationErrorNullNotAllowed, for that object.
The pages, the help file, and the changelog entry now say so.
The tests of the CSV route read a CSV file with Import-Csv, the route
that the documentation shows, instead of ConvertFrom-Csv of strings,
which makes a trailing blank cell $null. They pin the blank cell as the
default scope and the $null object as a binding error for that object
only, with the other objects processed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
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>
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>
With the culture of the thread tr-TR, the case-insensitive WildcardPattern that
compares each name with the filter treats I and i as different letters. The
enumeration had already matched the name without regard to the culture, so the
cmdlet dropped the items whose names differ from the filter in the case of an
I: -Filter 'index*' returned nothing for Index.txt, and -Filter '*.ini' did not
return SETTINGS.INI. Both editions. The independent review of the coverage
report found it; the scan of culture-sensitive calls had not listed
WildcardPattern.
The test sets the culture of the thread to tr-TR. On the previous build it
fails in the four configurations (3 of 134 cases of ItemCmdlets.Tests.ps1:
index*, *.ini, and *.INI; INDEX* is the control). The pattern is now
WildcardOptions.CultureInvariant.
The changelog entry of the identity comparison named the operator -eq, which
tr-TR never affected (probes on the previous build: -eq, -contains, and -in
return True for every case); it now names the method Equals.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
IdentityReference2.Equals(string) lowercased both names with ToLower(), which uses the
culture of the thread. In tr-TR, I becomes U+0131, so an account whose name holds an
uppercase I (NT AUTHORITY\SYSTEM, BUILTIN\Administrators) no longer matched the same name in
another case, for example $entry.Account -eq 'nt authority\system'. Compare with
StringComparison.OrdinalIgnoreCase.
The test sets the culture of the thread to tr-TR and compares the system account with its name
in three cases. Before the fix it fails in all four configurations (elevated and basic user,
Windows PowerShell 5.1 and PowerShell 7); after it, all rows pass. The unit suite under tr-TR
did not find it, because no test compares a name that holds an uppercase I.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
On a computer in a domain, Get-NTFSEffectiveAccess wrote "Access is denied"
and no result for every user who wasn't an administrator of the computer,
also for the default -ServerName localhost and for every other name of this
computer. The remote interface of the authorization manager of a computer
answers only its administrators and the members of Access Control Assistance
Operators, and a computer in a domain offers that interface to every caller.
On a computer outside a domain the interface is not reachable, so the cmdlet
already used the local authorization manager there, which is why the tests
passed on the development host and on the CI runners.
For a name of this computer, the cmdlet now uses the local authorization
manager when the remote one refuses the user. That manager is the one the name
asks for, and it answered correctly in every probe on Windows Server 2019,
2022, and 2025 and on Windows 11: for a standard domain user, a local standard
user, and an administrator with a filtered token, for the user's own account,
Everyone, the Administrator of the computer, and the Administrator and Domain
Users of the domain. For the name of another computer, the denial stays an
error, as the cmdlet page and the live test of the delegated account describe.
Twenty tests of the suite failed in the basic-user mode on every domain-joined
machine of the operating-system matrix, with the published 5.0.0-rc7 code and
with the code before this change, and pass with it (Windows Server 2019: basic
user 782 and 780 passed, 0 failed, in Windows PowerShell and PowerShell 7). A
new live test runs the case as the administrator of the file server, who isn't
an administrator of the client.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The module's own tests ran on Windows Server 2019, 2022, and 2025 and on
Windows 11 in the operating-system matrix. Two tests failed on every
domain-joined machine and passed on the development host:
- Get-NTFSInheritance -SecurityDescriptor reported AuditInheritanceEnabled
as $false for an item without audit entries, where -Path reported $true.
On these computers Windows reports the SACL as protected from
inheritance when it reads all sections together, and as not protected
when it reads the SACL alone. The descriptor now takes the audit section
from a separate read, like it already did for the access section. Write()
stores the sections that were read, so a descriptor with the wrong flag
would also have written the SACL back as protected.
- Get-NTFSEffectiveAccess -ServerName '' wrote an "Access is denied"
error on computers where Windows takes an empty name for this computer.
An empty name no longer asks the remote interface of the authorization
manager; the cmdlet warns and returns the result of this computer, like
for any name that can't be reached.
The existing tests that found them stay as the regression guards: they were
red on three virtual machines (Windows Server 2022 and 2025, Windows 11)
and are green after the change. Three tests are new: the audit state of a
file and a folder without audit entries, and of a file and a folder with
disabled audit inheritance, by path and by descriptor.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The cmdlet page said that the AlphaFS enumeration alone decides which names match, while the code compares each returned name with the pattern again; both apply, and the page now says so. The comment of PipelineControl said that every Write method is noted, but WriteWarning is not, and it names ShouldProcess as an example of an unnoted call. The changelog entries about the privileges name the cmdlets that enable them for the duration of their command, because Enable-Privileges keeps them enabled by design.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Get-ChildItem2 swallowed what a later command threw for the error of a nested folder, for example `Get-ChildItem2 -Recurse 2>&1 | ForEach-Object { throw 'x' }`: the recursion took it for a failure of the folder above, wrote a verbose message, and left the loop over the folders, so the listing ended early and the caller never saw the exception. BaseCmdlet now notes the exception that WriteError raises, as it does for WriteObject, WriteVerbose, and WriteDebug. The report that -ErrorAction Stop is swallowed there too was not reproducible (the error reaches the caller), and a break or Select-Object -First was already passed on by type; the tests keep both.
A cmdlet that enables the privileges wrote the debug message "..enabled" before it noted the privilege, so a later command that ended the pipeline or threw at that message left the privilege enabled: Dispose disables only what is noted. TryEnablePrivilege also took the exception of a later command for a failure to enable the privilege and went on with the next one, so `Get-NTFSOwner 5>&1 | ForEach-Object { if ($_.Message -eq '..enabled') { throw 'x' } }` enabled all four privileges and hid the exception. The privilege is noted before the message, and TryEnablePrivilege passes the exception on.
Red before the fix in the Release build of 7aa8315: three tests (the throw on the error stream, in four configurations the first, in the two elevated ones the two privilege tests). Also covers the typed-throw rows that fail if PowerShell stops wrapping a thrown exception, and Enable-Privileges in a script named NTFSSecurity.Init.ps1.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
A throw in a later command, or an error with -ErrorAction Stop, reaches a cmdlet through its Write call as an ordinary exception. The catch for the failures of an item reported it as the error of that item and went on, so that Remove-Item2 -PassThru removed the next item after a throw, and the caller never saw the exception. The earlier check found only the end of the pipeline and a break or continue. BaseCmdlet now notes the exception that its WriteObject, WriteVerbose, and WriteDebug raised, and every catch that can enclose a write passes it on; Get-DiskSpace writes outside its try. Set-NTFSSecurityDescriptor and Get-FileHash2 also caught it at a verbose message.
Get-ChildItem2 -Filter *.* returns every item, as Get-ChildItem does. The cmdlet compared each name with the pattern again and dropped the items without a dot, most folders among them; the dot stays an ordinary character in other patterns.
The failed lookup of InheritedFrom frees its native buffer. The help paragraph of -Filter has no pair of asterisks, which platyPS turns into emphasis, and the page has an example for *.*.
Review of the independent pass: the restored-owner test asserts that a plain write is denied, the drive-mapping helper has guard tests and takes letters that the no-volume tests do not, and the pipeline tests cover a throw, an error with -ErrorAction Stop, and the verbose and debug streams for every cmdlet that can reach the code.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The escape of brackets in the pattern read the filter before the pattern could reject it, so a null filter ended in a NullReferenceException. The parameter now rejects null with a validation error that names it; an empty filter still matches no item.
The cmdlet compares each name that the enumeration returns with the pattern again. The two disagree for *.*: the enumeration returns every item, as Get-ChildItem does, and the comparison drops the names without a dot, files and folders alike. A test pins this and reaches the branch that drops an item; the help says that a dot is an ordinary character.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The cmdlet compares the name of every item that the enumeration returns with the pattern again, and it built that comparison with the wildcard syntax of PowerShell. A bracket then began a character class, so Report[1].txt was returned by the enumeration, which treats a bracket as itself, and dropped by the comparison, and a file with brackets in its name could not be found for its name with -Filter, which Get-ChildItem does. The documentation names only * and ? as wildcards, so a bracket and a backtick now stand for themselves in the comparison.
The regression test fails without the fix in all four configurations. The probe also showed that AlphaFS compares only the long name, so the test for *.htm guards the documented contract and no 8.3 behavior. The page of the cmdlet names the rule and the help file is generated again.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
A catch for the failures of an item wrapped the write of its object. When a later command ended the pipeline, a break or continue in a script block or Select-Object -First, the exception passed through that catch, which reported it as an error of the item and went on with the next one. Remove-Item2, Copy-Item2, and Move-Item2 with -PassThru then removed, copied, or moved every item although the caller had ended the pipeline, and Set-NTFSOwner and Set-NTFSSecurityDescriptor changed every item. Get-NTFSSecurityDescriptor, Get-NTFSSimpleAccess, and Get-DiskSpace ignored the break, and Get-ChildItem2 ignored it for items below the first folder.
A helper recognizes the end of the pipeline and the control-flow exceptions of PowerShell by their base type, and these catches pass them on. The new table-driven tests run every cmdlet that writes objects: 26 cases for the nine cmdlets fail without the fix in all four configurations and the 64 cases of the others pass.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
When Windows cannot name the folder of an inherited entry, such as for an item that was deleted after its descriptor was read or for a folder above it that the user cannot read, the module fills InheritedFrom with a fallback text. The callers removed the last character of every source, which belongs to the trailing backslash of a real folder, so the fallback read 'unknown paren'. The fallback also named an unknown parent for explicit entries, which have no source. Remove only a trailing backslash, and name an unknown parent for inherited entries only.
The regression tests fail without the fix in all four configurations for access entries and in both elevated configurations for audit entries. The cmdlet pages name the text, and the help file is generated again.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Clear-NTFSAccess -DisableInheritance and Set-NTFSSecurityDescriptor took ownership of an item that the user owned already, left a DACL without the right to set an owner, and then reported a RestoreOwnerError for setting the same owner back. Skip the restore when the previous owner is the current user. The guards fail without the fix in all four configurations and also cover the owner that cannot be set back without the Restore privilege, the missing path of Get-ChildItem2, and the descriptor write that retries as owner.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Reproduce and fix public rule paths, simplified audit comparisons and ReadData conversion, and boxed privilege equality. Add behavior guards for descriptor inheritance, unresolved identities, audit capability and recursive denial. Freeze this source for Release matrix measurement; final gate evidence and independent review follow.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Where a computer doesn't offer the remote interface of the authorization
manager, the cmdlet calculates the result with the local one and warns
that the result might be inaccurate. Only localhost in lowercase counted
as this computer, so the cmdlet warned that the computer couldn't be
reached for ., LOCALHOST, or the computer name, although the local result
is the result of that computer. A name of this computer is now localhost
in any case, ., the NetBIOS name, the DNS host name, or the fully
qualified domain name.
From the security-reviewer pass over be04cb7..4ee01e5 (Nit 7),
reproduced in Windows PowerShell 5.1 and PowerShell 7 on a workstation
without the remote interface.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
From the security-reviewer pass over be04cb7..4ee01e5 (Minor 3 and 4):
ea2f6df compares the paths of folders without regard to case, which no
test covered; a parent folder in another case counted as not reported
before, so the folder was left out. The test of a drive root now expects
all of its entries instead of any. The page and the changelog say that
paths that differ only in case name the same folder.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
From the security-reviewer pass over be04cb7..4ee01e5 (Minor 1, 2, and
5, Nit 9):
- A path with a character that Windows doesn't allow, such as |, stopped
the pipeline in Windows PowerShell, where resolving the path throws an
ArgumentException; both cmdlets now write a non-terminating error with
the category InvalidArgument, also in PowerShell 7, where AlphaFS
rejects the path when it creates the link.
- The errors of New-NTFSSymbolicLink for an existing -Path and a missing
-Target, and of New-NTFSHardLink for a folder as -Target, named no path.
- New-NTFSSymbolicLink checked -Target before -Path, so that the two
cmdlets reported different errors for an existing -Path with a missing
-Target; both check -Path first now.
- The pages list objects with Path and Target as input of their own.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
New-NTFSHardLink and New-NTFSSymbolicLink now require -Path and -Target.
Without -Path, they failed with an index error; without -Target, they
used the current location, so New-NTFSSymbolicLink -Path Link created a
link to the current folder.
For a link that they can't create, they write a non-terminating
CreateHardLinkError or CreateSymbolicLinkError with the category
ResourceExists, ObjectNotFound, InvalidArgument, PermissionDenied, or
WriteError, and continue with the next object from the pipeline; they
stopped with a terminating error.
Fixed on the way: every object piped to the cmdlets failed with
GetDefaultValueFailed, because PowerShell reads a parameter that takes
pipeline input before it binds the input, and the getter of -Path threw
on the empty list. The pages show piping rows of a CSV file.
BREAKING CHANGE: a script that omits -Path or -Target gets a prompt, or
an error in a non-interactive session, and a script that relies on a
terminating error of the link cmdlets needs -ErrorAction Stop.
Decision 22, items 7 and 8: assumptions in autopilot, flagged for the
maintainer's review.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Windows can't move a folder to another volume. Move-Item2 moved folders
with CopyAllowed, so AlphaFS copied and deleted them instead: an empty
folder was deleted without being created at the destination, and a
folder with files failed with an error that named one of its files.
Folders now move without CopyAllowed, and the cmdlet writes a MoveError
with the category InvalidOperation that names the folder and the
destination, and leaves the folder in place. A file still moves to
another volume; with -Force, it keeps the error of Windows, (17).
The tests move to \\localhost\C$, which Windows treats as another volume,
and run only elevated.
Decision 22, item 6: an assumption in autopilot, flagged for the
maintainer's review.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
When the computer of -ServerName can't be reached, the cmdlet calculates
the result with the group memberships known on this computer and warns.
The warning now names that computer, which a command with many items
couldn't tell otherwise. The live test expects the new text as well.
Decision 22, item 5: an assumption in autopilot, flagged for the
maintainer's review.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Get-NTFSSimpleAccess compares each folder with its parent folder. A
folder whose parent folder it hadn't reported was left out, and with it
all of its subfolders; a drive root, which has no parent folder, was left
out or compared with the parent folder of the folder before it; and a
folder that came after its parent folder a second time failed with a
ReadError, "An item with the same key has already been added". Such
folders are now reported with all of their entries, and the paths are
compared without regard to case.
Decision 22, item 2: an assumption in autopilot, flagged for the
maintainer's review.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Without the Security privilege, Get-NTFSOrphanedAudit read the item
without its SACL and returned nothing, which looked like an item without
orphaned entries, and it wrote a warning for an item that it couldn't
read. It now reads only the SACL, like Get-NTFSAudit, and writes a
ReadSecurityError with the category PermissionDenied or OpenError. The
error for a path that doesn't exist stays ReadError.
Decision 22, item 1: an assumption in autopilot, flagged for the
maintainer's review.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
- The conversions of a FileSystemSecurity2 to FileSecurity and
DirectorySecurity returned fields that were never set, so they gave
null; they return the descriptor, and the dead fields are gone
(finding 1).
- Equals of the entries and descriptors accepted the .NET type as well,
which doesn't know the wrapper, so equality depended on the direction;
only an object of the module can now be equal (finding 2).
- Invoke-TestsAsBasicUser.ps1 refuses a title with a line break, also a
final one, which $ let through (finding 6).
- The InheritedFrom test of the access entries checks a known parent
folder with two explicit entries in front; it fails on acfe3af
(finding 7).
Checked and kept: a callback ACE before the inherited entries doesn't
shift InheritedFrom, because .NET returns it as a rule (finding 3).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Equals of FileSystemAccessRule2, FileSystemAuditRule2, and
FileSystemSecurity2 cast its argument to the .NET type, which throws for
the wrapper types themselves: -eq and -contains, and in PowerShell 7 also
Select-Object -Unique and Compare-Object, stopped with an
InvalidCastException. GetHashCode of FileSystemSecurity2 read a field
that is never set and threw a NullReferenceException. Two objects are now
equal when they hold the same entry or descriptor, like the .NET types.
InheritedFrom: Win32.GetInheritedFrom returned the sources of the SACL
whenever the descriptor had one, also for the access entries, and the
callers gave the filtered entries of -ExcludeExplicit the sources of the
first entries of the ACL. Get-NTFSAccess -SecurityDescriptor stopped with
an ArgumentOutOfRangeException for a descriptor with audit entries, as
Get-NTFSSecurityDescriptor reads them in an elevated session. The method
now takes the ACL of the entries, and the callers map the sources before
they filter.
The coverage report of rc6 pointed at both; each test fails without its
fix.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
GetRelativePath treated every path that started with a dot as .\path and
dropped its first two characters, so a command on .gitignore read,
changed, or removed itignore in the same folder when that item existed;
Remove-Item2 -Path .RemoveMe removed emoveMe, and Copy-Item2 -Force with
the destination .CopyTarget overwrote opyTarget. Only .\ and ./ are now
stripped, and only .. and ..\ go up a folder; any other name is combined
with the current location. All path parameters resolve through this
method: -Path, -Destination, and -Target.
The coverage report of rc6 found the untested branch. The tests use a
decoy item with the shortened name and fail without the fix.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
- Copy-Item2 and Move-Item2 name a missing destination folder in a verbose
message with -WhatIf, like an existing destination (#108); the operation
itself fails with an error that names the folder (finding 1).
- Invoke-TestsAsBasicUser.ps1 refuses a title with a double quote or a
percent sign, which cmd.exe interprets inside the quoted argument, and
fails when waiting for the test process fails (findings 4 and 5).
- The page of Get-NTFSSimpleAccess says that ReadData is the right to list
a folder (ListDirectory), which the cmdlet reports as Read (finding 10).
Checked and kept: a UNC destination on a share that doesn't exist names
the share, which a new test pins (finding 3); the lab script refuses
machines outside the lab before it changes anything (finding 6).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The authorization manager of a computer answers only its administrators
and the members of its group Access Control Assistance Operators
(S-1-5-32-579); any other account gets "Access is denied" and no result.
A probe in the lab confirmed it on 2026-10-08: the delegated account got
error 5 without the membership and its rights with it.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Add tests for the error handling that the cmdlets with -Path share: a
path that doesn't exist (16 cmdlets, and 6 audit cmdlets with the
Security privilege), an item whose owner may not read its permissions
(6 cmdlets), and an item whose owner may not change them, which the 6
cmdlets that write the DACL handle by taking ownership. Each error
belongs to its path only, and the cmdlet goes on with the next one.
The tests found one defect: Get-NTFSOrphanedAccess reported an item that
it couldn't read as an AddAceError with the category WriteError. It now
writes a ReadSecurityError, like Get-NTFSAccess.
They also show that the take-ownership retry works without privileges
when the account holds the Take Ownership right and may assign the
previous owner, and that it can't help a denied read, because reading
the owner needs the same right. Concepts and five cmdlet pages said that
the retry needs the privileges; they now describe both, and that Windows
removes the OWNER RIGHTS entries when the owner changes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The cmdlet read the item again for -PassThru inside the try block that
retries a denied write as the owner (R5 of the review of #113). A read
that was denied after a successful write therefore started another
attempt of the write and ended in a WriteSdError, and a write that
needed the ownership retry wrote no object at all.
The read now follows the write and its retry, and a failed read is a
ReadSecurityError. The page also says what happens when setting the
previous owner back fails.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Windows can't list the names of a file on a network share and answers
with (50) The request is not supported. The new live tests found that
Get-NTFSHardLink then stopped with a terminating error, so that it
skipped the remaining paths, and that New-NTFSHardLink -PassThru did so
after it had created the link. A folder stopped Get-NTFSHardLink the
same way.
Both cmdlets now write a non-terminating GetHardLinkError and go on.
The tests reach the sandbox over the administrative share of its drive,
which behaves like the share of a file server, and skip where that share
isn't available, such as for a basic user. The pages describe the limit
on shares.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The check for an existing destination looked for a file only. For a
folder whose name existed at the destination, the cmdlets failed in the
middle with a CopyError or a MoveError, and Copy-Item2 could copy a part
of the folder first. They now write DestinationFileAlreadyExists, as
for a file.
When the folder that is to contain the new item didn't exist, AlphaFS
reported a DirectoryNotFoundException that named the source item, which
reproduces the symptom of #21. The cmdlets now write an error that names
the missing folder, with the destination as the target. Copy-Item2 no
longer creates the missing folders for a folder: the workaround that
creates the destination folder for AlphaFS created its parents as well,
which only the prereleases of 5.0.0 did.
The pages also say that -Force merges a folder into an existing folder
of the same name, and that a folder can't move to another volume.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Two deviations from the cmdlet page, found by new tests from its
contract:
- An entry that grants only ReadData became None: the reduction tested
the combined Read mask, and nothing mapped ReadData alone. .NET adds
Synchronize to every allow entry, which hid it; other tools write such
entries.
- With -IncludeRootFolder, on by default, a relative path with a single
folder name had no parent folder in the result, because the parent was
taken from the path before it was resolved.
The tests also cover the rights reduction, the comparison of folders
with their parent, the pipeline, the current location, -ExcludeExplicit,
files, and missing paths, elevated and as a basic user in both editions.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Since this branch, Test-Path2 writes $false for a path that Windows
PowerShell rejects, such as one with a |, but it didn't say why. It now
writes the reason as a debug message. Only the lookup of the item is in
the try block, so that an error elsewhere in the cmdlet can't turn into
$false.
Found by the security review of fcb370e..00c3646 (finding 4).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
A cmdlet that enables the Backup, Restore, Take Ownership, and Security
privileges decided which ones to disable on the states that it had read
when it enabled them, and stopped at the first one that failed. When
another command in the pipeline, such as Disable-Privileges, had disabled
one of them, the cmdlet stopped with "Priviledge already disabled" and
left the privileges after that one enabled. After an early stop, which
Dispose handles since this branch, it left them enabled without any
message, because PowerShell ignores exceptions thrown in Dispose; and
Disable-Privileges threw that exception in Dispose on every call while
the privileges were disabled. 4.2.6 already decided on the old states.
DisablePrivilege now reads the current state, and the cleanup tries every
privilege: in EndProcessing, a privilege that it can't disable gives a
warning; in Dispose, it is ignored.
The early-stop tests now pin EnablePrivileges and check that the cmdlet
had enabled the privileges, so that they can't pass without testing
anything.
Found by the security review of fcb370e..00c3646 (findings 1 to 3).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
In Windows PowerShell, .NET rejects a path with a character that Windows
doesn't allow in names, such as | or <, and Test-Path2 stopped with the
terminating error "Illegal characters in path". Such an item can't
exist, so the cmdlet now writes false, as in PowerShell 7 and like
Test-Path. Add tests for every -PathType, long paths, relative paths,
and the pipeline, and for Get-DiskSpace, which had no tests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The cmdlets that enable the Backup, Restore, Take Ownership, and Security
privileges disabled them only in EndProcessing, which PowerShell skips
when a later command, such as Select-Object -First, or a terminating
error stops the pipeline. The privileges then stayed enabled in the
session. BaseCmdletWithPrivControl now implements IDisposable and
disables them in Dispose as well; Enable-Privileges keeps them.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Get-NTFSEffectiveAccess -ServerName with a computer that can't be
resolved or reached returned no access, while it warned that it had
calculated the result on this computer. In that case,
AuthzInitializeRemoteResourceManager fails with RPC_S_SERVER_UNAVAILABLE
(1722); the code fell back to the local authorization manager only for
EPT_S_NOT_REGISTERED (1753), and GetEffectiveAccess swallowed the
exception. It now falls back for 1722 as well, as the cmdlet page
describes. The live tests in a lab found it; the new test in
Access.Tests.ps1 reproduces it on any computer.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
- Read the root folder for a volume name such as \\?\Volume{GUID}\ too,
like for a drive letter, and accept only the letters A to Z as a drive
- Report a security descriptor without the audit entries without naming a
missing Security privilege as the cause, which may not be the reason
- Skip the audit tests that change a descriptor from
Get-NTFSSecurityDescriptor in a session without the Security privilege
- Assert the absence of the old hint in the Get-NTFSEffectiveAccess test
- Narrow the drive-root note of Get-NTFSAccess to the security cmdlets
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
- #41: for the root of a drive, the cmdlets read and changed the security
descriptor of the drive, a device object. FileSystemSecurity2 now routes
drive roots through the path-based AlphaFS methods, which keep the
trailing backslash; the removal and inheritance helpers use it too.
- #109: Add-, Remove-, and Clear-NTFSAudit report a security descriptor
without the audit entries like Get-NTFSAudit, through one helper, and
Get-NTFSEffectiveAccess names the cause that Windows reported instead
of a missing Security privilege.
- #108: Copy-Item2 and Move-Item2 check the destination only for an
operation that runs; with -WhatIf, a verbose message names the conflict.
- #111: Disable-Privileges skips the privileges that the token doesn't
hold, the privilege messages are spelled right, and Get-FileHash2
declares the type name of its objects; 05-Releasing.md documents the
release metadata tests.
- rc3 review leftovers: Remove-NTFSAudit writes nothing for an item
without a SACL, the owner retry of Set-NTFSSecurityDescriptor restores
the previous owner in a finally block and keeps an owner that the
descriptor sets, and FileSystemSecurity2.Write with another item writes
only the sections that were read.
Each fix has a test that failed first, in Windows PowerShell 5.1 and
PowerShell 7; writing a drive root was checked once on a temporary VHD.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
- Set-NTFSSecurityDescriptor -Verbose names the sections that it writes,
or says that it writes nothing for an unchanged descriptor; its page
says "since it was read or last written" (review F-02).
- The pages of Enable-NTFSAccessInheritance, Disable-NTFSAccessInheritance,
and Set-NTFSInheritance get the #34 note, like the other fixed cmdlets
(review F-06).
- Set-TestOwner throws its own error when icacls fails, also when the
caller uses -ErrorAction Stop in Windows PowerShell (review F-07).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
The access and audit cmdlets wrote the owner of an item back with the
entries they changed. For a DACL without the auto-inherit flag, Windows
returns the owner and the group even when only the DACL is read, and the
cmdlets wrote every section that the descriptor held. Without the Restore
privilege, or on a file server that refuses the owner, the write failed
with error 1307 (#34).
- Add-NTFSAccess, Clear-NTFSAccess, Add-NTFSAudit, and Clear-NTFSAudit
read only the DACL or the SACL. FileSystemSecurity2.Write(),
Remove-NTFSAccess, and Remove-NTFSAudit write only the sections they
read, which also fixes the access inheritance cmdlets.
- Read together with the SACL, the inherited entries of such a DACL lose
their inherited flag when the parent folder has no SACL, and the
cmdlets stored them as explicit copies. Get-NTFSSecurityDescriptor now
reads the DACL in a separate call.
- Set-NTFSSecurityDescriptor writes only the sections that changed since
they were read; an unchanged descriptor writes nothing (maintainer
decision of 2026-10-06).
- Clear-NTFSAudit writes nothing for an item without a SACL, and reports
an error without the Security privilege (maintainer decision).
The regression tests failed before and pass after the fix in Windows
PowerShell 5.1 and PowerShell 7, elevated and as a basic user.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
NTFSSecurity will be archived soon. The README, the documentation home,
which is also the wiki home, and the changelog now point users to
WindowsAccessControl, which is on the PowerShell Gallery. The changelog
entry also reaches the release notes of the next prerelease.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Enable-NTFSAuditInheritance, Disable-NTFSAuditInheritance, and
Set-NTFSInheritance -AuditInheritanceEnabled failed with "(5) Access is
denied" for a file or folder without a SACL, also elevated with the
Security privilege. The cmdlets read only the audit section and changed
the flag that disables or enables audit inheritance. AlphaFS writes that
flag only together with a SACL, so it wrote no section at all, which
Windows denies; the retry as owner repeated the same write. An empty SACL
is now added first, but only to a descriptor that was read with its SACL.
The elevated CI runs of #100 to #106 showed this through the test of an
omitted -AccessInheritanceEnabled. From #104 on, the test that keeps the
inherited entries of a security descriptor failed as well: elevated,
Get-NTFSSecurityDescriptor reads the SACL, and Windows then returns a DACL
that isn't in the auto-inherit format, such as that of a file in the temp
folder of the user, without its inherited flags. The test now reads the
access section only and checks that the descriptor has inherited entries.
Tests: five cases for items without audit entries, red with "Access is
denied" before the fix; the test that keeps the explicit audit entries now
checks the errors and the inheritance state of both calls; a test checks
that a descriptor read without its audit entries gets no SACL, which would
replace the audit entries of the item when it is written.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Raimund Andree