Get-NTFSOrphanedAccess wrote a warning ("Could not read item {0}. The
error was: {1}") for a read failure that is not an access denial, while
every sibling (Get-NTFSAccess, Get-NTFSAudit, Get-NTFSEffectiveAccess,
Get-NTFSInheritance, Get-NTFSSecurityDescriptor) writes a non-terminating
error and goes on with the next item. The cmdlet now writes
ReadSecurityError, categorized as OpenError and targeting the path,
through WriteError, then continues, the same pattern
Get-NTFSAccess (GetAccess.cs) already uses for the same kind of failure.
A script that collected this warning with -WarningVariable now has to
read $Error or -ErrorVariable instead.
No existing test pinned the warning (searched for "Could not read item"
and Get-NTFSOrphanedAccess with -WarningVariable across Tests\; none
found), so none needed changing.
NOT DONE: a new test that triggers this exact catch (a read failure that
is not UnauthorizedAccessException) through the public surface. Five
probes (..\probes-wi2\p-orphaned-read-failure*.ps1) tried a sharing
lock, an over-long path, a dangling and a looped junction, and an
alternate data stream; none reached this catch without also failing
GetFileSystemInfo2 first (a different error, ReadFileError) or succeeding
outright, because an elevated session that can read the item at all can
read its ACL as well. The change is still correct and matches the
module's convention; it is defensive code for a condition this harness
cannot construct deterministically.
Docs\Cmdlets\Get-NTFSOrphanedAccess.md documents the new error next to
the existing ReadSecurityError paragraph for the access-denied case.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: AI Assistant <ai@example.com>
Raimund Andree