From 25fe77500e72b30ae82976695c6ec72733cde78e Mon Sep 17 00:00:00 2001 From: Raimund Andree Date: Tue, 20 Oct 2026 09:28:21 +0000 Subject: [PATCH 1/4] fix(access): report what the initialization of the authorization manager throws 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 --- CHANGELOG.md | 9 +++++ Docs/Cmdlets/Get-NTFSEffectiveAccess.md | 2 + .../AccessCmdlets/GetEffectiveAccess.cs | 3 +- NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml | 1 + Security2/Win32/Lib.cs | 24 +++++------ Tests/Access.Tests.ps1 | 40 +++++++++++++++++++ 6 files changed, 64 insertions(+), 15 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index c89017e..ed30f29 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -207,6 +207,15 @@ The format is based on Operators. It now uses the local authorization manager of this computer when the remote one refuses the user, as it already did when the remote one can't be reached. For the name of another computer, the error stays +- Fix `Get-NTFSEffectiveAccess`, which returned no access and no error when + Windows refused to start the authorization manager for the computer of + `-ServerName`, for example for a name of 32,718 characters or more: the + result looked like an account without any rights. The cmdlet now writes + a `GetEffectiveAccessError` with the error that Windows reported and + returns no result, as it does when a later step of the calculation fails. + The warning that the result is based on this computer now comes only with + a result; it also came before an error when the computer couldn't be + reached - Fix `Get-NTFSOwner`, which wrote a "The pipeline has been stopped" error for every path when a command such as `Select-Object -First 1` stopped the pipeline, and which repeated a failed read instead of reporting the diff --git a/Docs/Cmdlets/Get-NTFSEffectiveAccess.md b/Docs/Cmdlets/Get-NTFSEffectiveAccess.md index 756bfe9..ae756e0 100644 --- a/Docs/Cmdlets/Get-NTFSEffectiveAccess.md +++ b/Docs/Cmdlets/Get-NTFSEffectiveAccess.md @@ -188,6 +188,8 @@ Before 5.0.0-rc7, the warning about a computer that couldn't be reached didn't n Before 5.0.0-rc7, a user who wasn't an administrator got the error "Access is denied" and no result on a computer in a domain, also for a name of this computer, such as the default `localhost`. +Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it returns a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached. + ## RELATED LINKS [Get-NTFSAccess](Get-NTFSAccess.md) diff --git a/NTFSSecurity/AccessCmdlets/GetEffectiveAccess.cs b/NTFSSecurity/AccessCmdlets/GetEffectiveAccess.cs index c8468af..01ab384 100644 --- a/NTFSSecurity/AccessCmdlets/GetEffectiveAccess.cs +++ b/NTFSSecurity/AccessCmdlets/GetEffectiveAccess.cs @@ -157,7 +157,8 @@ namespace NTFSSecurity private void WriteEffectiveAccess(EffectiveAccessInfo result, object target) { - if (!result.FromRemote) + // The warning qualifies a result, which an error leaves out. Before 5.0.0-rc8, it came before the error, too. + if (!result.FromRemote && !result.OperationFailed) { // Since 5.0.0-rc7, the warning names the computer, which a command with many items can't tell otherwise. WriteWarning(string.Format("The effective rights can only be computed based on group membership on this computer, " + diff --git a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml index 10c2eeb..e440a11 100644 --- a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml +++ b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml @@ -5169,6 +5169,7 @@ PS C:\> Get-NTFSAudit -SecurityDescriptor $sd Before 5.0.0, `-ExcludeNoneAccessEntries` had no effect, and the cmdlet returned nothing without `-Path` or for `-SecurityDescriptor`. When the computer of `-ServerName` couldn't be reached, the cmdlet warned that it had calculated the result on this computer, but returned no access instead of that result. Before 5.0.0-rc7, the warning about a computer that couldn't be reached didn't name the computer, and the cmdlet warned for every name of this computer except `localhost` in lowercase, such as `.`, `LOCALHOST`, or the computer name. Before 5.0.0-rc7, a user who wasn't an administrator got the error "Access is denied" and no result on a computer in a domain, also for a name of this computer, such as the default `localhost`. + Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it returns a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached. diff --git a/Security2/Win32/Lib.cs b/Security2/Win32/Lib.cs index 9a5c32b..67353d2 100644 --- a/Security2/Win32/Lib.cs +++ b/Security2/Win32/Lib.cs @@ -125,19 +125,15 @@ namespace Security2 try { GetEffectivePermissions_AuthzInitializeResourceManager(serverName, out remoteServerAvailable); - - try - { - GetEffectivePermissions_AuthzInitializeContextFromSid(identity); - effectiveAccess = GetEffectivePermissions_AuthzAccessCheck(sd); - } - catch (Exception ex) - { - authzException = ex; - } + GetEffectivePermissions_AuthzInitializeContextFromSid(identity); + effectiveAccess = GetEffectivePermissions_AuthzAccessCheck(sd); + } + catch (Exception ex) + { + // Also what the initialization of the resource manager throws. Before 5.0.0-rc8, that was ignored, and + // the caller got no access without an error. + authzException = ex; } - catch - { } finally { GetEffectivePermissions_FreeResouces(); @@ -148,8 +144,8 @@ namespace Security2 #region Win32 Wrapper // Whether a name of -ServerName names this computer: localhost in any case, ., the NetBIOS name, the DNS host - // name, or the fully qualified domain name. It must not throw, because GetEffectiveAccess hides every exception - // of the resource manager behind a result without access. + // name, or the fully qualified domain name. It answers false when it can't tell and doesn't throw, so that the + // fallback for a computer that can't be reached doesn't fail on this question. private static bool IsLocalComputer(string serverName) { if (string.IsNullOrEmpty(serverName)) diff --git a/Tests/Access.Tests.ps1 b/Tests/Access.Tests.ps1 index 62bc669..5b70d0f 100644 --- a/Tests/Access.Tests.ps1 +++ b/Tests/Access.Tests.ps1 @@ -169,6 +169,46 @@ Describe 'Get-NTFSEffectiveAccess' { "because the computer '' can't be reached for a remote access check. " + 'For more accurate results, calculate effective access rights on that computer.') } + + # The warning says that the result is the one of this computer, so it has no place before an error that leaves + # no result. Before 5.0.0-rc8, the cmdlet warned and then wrote the error for an account that Windows can't resolve. + It 'Should write the error and no warning about this computer for an identity that cannot be resolved' { + $identity = [Security2.IdentityReference2] 'S-1-5-21-1-2-3-1001' + $identity.AccountName | Should -BeNullOrEmpty + + $result = @(Get-NTFSEffectiveAccess -Path $effectiveFile -Account $identity -ServerName 'ntfssecurity-test.invalid' -WarningVariable accessWarnings -WarningAction SilentlyContinue -ErrorVariable accessErrors -ErrorAction SilentlyContinue) + + $result | Should -BeNullOrEmpty + $accessErrors | Should -HaveCount 1 + $accessErrors[0].FullyQualifiedErrorId | Should -BeLike 'GetEffectiveAccessError,*' + @($accessWarnings.Message | Where-Object -FilterScript { $_ -like '*can''t be reached for a remote access check*' }) | Should -BeNullOrEmpty + } + } + + # Before 5.0.0-rc8, the cmdlet ignored what the initialization of the authorization manager threw and returned no + # access without an error, which looks like an account without rights. On Windows Server 2025, a name of 32,718 + # characters or more fails there with the error 14, "Not enough memory resources are available to complete this + # operation", while a shorter name gets RPC server unavailable, and the cmdlet falls back to this computer. Another + # version of Windows may answer the long name like the short one, so the test accepts both outcomes and fails for + # no access without an error. + Context 'When Windows rejects the name of -ServerName' { + It 'Should write an error or return the result of this computer, never no access' { + $expected = Get-NTFSEffectiveAccess -Path $effectiveFile -WarningAction SilentlyContinue -ErrorAction Stop + [long] $expected.AccessRights | Should -BeGreaterThan ([long] [Security2.FileSystemRights2]::Synchronize) + + $result = @(Get-NTFSEffectiveAccess -Path $effectiveFile -ServerName ('a' * 40000) -WarningVariable accessWarnings -WarningAction SilentlyContinue -ErrorVariable accessErrors -ErrorAction SilentlyContinue) + + if ($accessErrors) { + $result | Should -BeNullOrEmpty + $accessErrors | Should -HaveCount 1 + $accessErrors[0].FullyQualifiedErrorId | Should -BeLike 'GetEffectiveAccessError,*' + @($accessWarnings.Message | Where-Object -FilterScript { $_ -like '*can''t be reached for a remote access check*' }) | Should -BeNullOrEmpty + } + else { + $result | Should -HaveCount 1 + $result[0].AccessRights | Should -Be $expected.AccessRights + } + } } # Not every computer offers the remote interface of the authorization manager; the cmdlet then calculates the result From 9f906248b50b032b7f6c93c575d056907cfe16e4 Mon Sep 17 00:00:00 2001 From: Raimund Andree Date: Tue, 20 Oct 2026 09:30:27 +0000 Subject: [PATCH 2/4] docs(links): document the limit of the hard-link cmdlets for subst drives and mount points 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 --- CHANGELOG.md | 8 ++++++++ Docs/Cmdlets/Get-NTFSHardLink.md | 2 ++ Docs/Cmdlets/New-NTFSHardLink.md | 2 ++ NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml | 2 ++ 4 files changed, 14 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index ed30f29..9fc8653 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -89,6 +89,14 @@ The format is based on `-ErrorAction Stop` - Name the computer in the warning of `Get-NTFSEffectiveAccess` when the computer of `-ServerName` can't be reached +- Document that `Get-NTFSHardLink` and `New-NTFSHardLink -PassThru` fail for + a path whose root isn't the root of the volume that holds the file, such + as a path on a drive made with `subst`. `Get-NTFSHardLink` writes a + `FileNotFound` error for a file that exists, and + `New-NTFSHardLink -PassThru` creates the link and then stops with a + `FileNotFoundException`. A volume that is mounted into a folder, and a + junction or symbolic link to another volume, probably fail the same way. + Use a path that starts at the root of the volume ### Deprecated diff --git a/Docs/Cmdlets/Get-NTFSHardLink.md b/Docs/Cmdlets/Get-NTFSHardLink.md index b1aefef..d3e37c9 100644 --- a/Docs/Cmdlets/Get-NTFSHardLink.md +++ b/Docs/Cmdlets/Get-NTFSHardLink.md @@ -104,6 +104,8 @@ Hard links exist only within a single NTFS volume. Every object that this cmdlet Windows can't list the names of a file on a network share, also when the share lies on an NTFS volume of the file server. For such a file the cmdlet writes a non-terminating `GetHardLinkError` with the message "The request is not supported" and continues with the next path; run the cmdlet on the file server itself instead. Before 5.0.0, a file on a network share and a folder stopped the cmdlet with a terminating error, so that it skipped the remaining paths. +The cmdlet combines the names that the file system reports with the root of the path that you pass in, which is right only when that root is the root of the volume that holds the file. For a path on a drive that you made with `subst`, the cmdlet writes a non-terminating `FileNotFound` error for a file that exists and returns no object; use `D:\Data\Report.txt` instead of `Z:\Report.txt` for the drive `Z:` that `subst Z: D:\Data` made. A volume that is mounted into a folder, and a junction or a symbolic link to another volume, probably behave the same way. Use a path that starts at the root of the volume. + Because all hard links of a file share the same data, they also share the file content, the file size, and the time stamps. The security descriptor is stored with the file as well, so changing permissions through one name changes them for every name. The cmdlet resolves paths through the AlphaFS library and therefore also works with paths that exceed the 260-character `MAX_PATH` limit. diff --git a/Docs/Cmdlets/New-NTFSHardLink.md b/Docs/Cmdlets/New-NTFSHardLink.md index 818cb7a..1b92041 100644 --- a/Docs/Cmdlets/New-NTFSHardLink.md +++ b/Docs/Cmdlets/New-NTFSHardLink.md @@ -150,6 +150,8 @@ Windows supports hard links only for files on the same NTFS volume. A link that The cmdlet creates hard links on a network share as well, but Windows can't list the names of a file there. With `-PassThru` on a share, the cmdlet creates the link and writes a non-terminating `GetHardLinkError` with the message "The request is not supported" instead of the objects. Before 5.0.0, it stopped with a terminating error after it had created the link. +With `-PassThru`, the cmdlet lists the names of the file like `Get-NTFSHardLink` and has its limit: when the root of `-Path` isn't the root of the volume that holds the file, such as for a drive that you made with `subst`, the cmdlet creates the link and then stops with a terminating `System.IO.FileNotFoundException`. The objects are missing, and the links that follow in the pipeline aren't created. A volume that is mounted into a folder, and a junction or a symbolic link to another volume, probably behave the same way. Use a path that starts at the root of the volume, or leave out `-PassThru`. + The cmdlet does not overwrite anything. If `-Path` already exists, if `-Target` is missing or is a folder, or if a path contains a character that Windows doesn't allow, such as `|`, the cmdlet writes a non-terminating `CreateHardLinkError` with the category `ResourceExists`, `ObjectNotFound`, or `InvalidArgument`, leaves the file system unchanged, and continues with the next object from the pipeline. It checks `-Path` before `-Target`, and the error for an existing `-Path`, a missing `-Target`, or a folder as `-Target` names that path. When Windows refuses the link, such as for a target on another volume, the cmdlet writes a `CreateHardLinkError` as well. Because all names of a file share the same data, the number of hard links is a property of the file, not of an individual name. Use `Get-NTFSHardLink` to list them, and delete a link with `Remove-Item2` or `Remove-Item`, which removes only that name as long as other names remain. diff --git a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml index e440a11..ab38c39 100644 --- a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml +++ b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml @@ -5307,6 +5307,7 @@ PS C:\> Get-NTFSAudit -SecurityDescriptor $sd Hard links exist only within a single NTFS volume. Every object that this cmdlet returns therefore refers to a path on the volume of the file that you passed in. Windows can't list the names of a file on a network share, also when the share lies on an NTFS volume of the file server. For such a file the cmdlet writes a non-terminating `GetHardLinkError` with the message "The request is not supported" and continues with the next path; run the cmdlet on the file server itself instead. Before 5.0.0, a file on a network share and a folder stopped the cmdlet with a terminating error, so that it skipped the remaining paths. + The cmdlet combines the names that the file system reports with the root of the path that you pass in, which is right only when that root is the root of the volume that holds the file. For a path on a drive that you made with `subst`, the cmdlet writes a non-terminating `FileNotFound` error for a file that exists and returns no object; use `D:\Data\Report.txt` instead of `Z:\Report.txt` for the drive `Z:` that `subst Z: D:\Data` made. A volume that is mounted into a folder, and a junction or a symbolic link to another volume, probably behave the same way. Use a path that starts at the root of the volume. Because all hard links of a file share the same data, they also share the file content, the file size, and the time stamps. The security descriptor is stored with the file as well, so changing permissions through one name changes them for every name. The cmdlet resolves paths through the AlphaFS library and therefore also works with paths that exceed the 260-character `MAX_PATH` limit. @@ -7191,6 +7192,7 @@ PS C:\Data> Get-NTFSSecurityDescriptor Windows supports hard links only for files on the same NTFS volume. A link that points to a file on another volume, or a target on a file system that does not implement hard links, cannot be created. The cmdlet creates hard links on a network share as well, but Windows can't list the names of a file there. With `-PassThru` on a share, the cmdlet creates the link and writes a non-terminating `GetHardLinkError` with the message "The request is not supported" instead of the objects. Before 5.0.0, it stopped with a terminating error after it had created the link. + With `-PassThru`, the cmdlet lists the names of the file like `Get-NTFSHardLink` and has its limit: when the root of `-Path` isn't the root of the volume that holds the file, such as for a drive that you made with `subst`, the cmdlet creates the link and then stops with a terminating `System.IO.FileNotFoundException`. The objects are missing, and the links that follow in the pipeline aren't created. A volume that is mounted into a folder, and a junction or a symbolic link to another volume, probably behave the same way. Use a path that starts at the root of the volume, or leave out `-PassThru`. The cmdlet does not overwrite anything. If `-Path` already exists, if `-Target` is missing or is a folder, or if a path contains a character that Windows doesn't allow, such as `|`, the cmdlet writes a non-terminating `CreateHardLinkError` with the category `ResourceExists`, `ObjectNotFound`, or `InvalidArgument`, leaves the file system unchanged, and continues with the next object from the pipeline. It checks `-Path` before `-Target`, and the error for an existing `-Path`, a missing `-Target`, or a folder as `-Target` names that path. When Windows refuses the link, such as for a target on another volume, the cmdlet writes a `CreateHardLinkError` as well. Because all names of a file share the same data, the number of hard links is a property of the file, not of an individual name. Use `Get-NTFSHardLink` to list them, and delete a link with `Remove-Item2` or `Remove-Item`, which removes only that name as long as other names remain. Before 5.0.0, the error for a missing `-Target` said "The target path exist", the opposite of the cause. From e2e9324eb9995e1c6f77c318188f0797b0306c61 Mon Sep 17 00:00:00 2001 From: Raimund Andree Date: Tue, 20 Oct 2026 09:37:00 +0000 Subject: [PATCH 3/4] chore(release): prepare 5.0.0-rc8 Set the prerelease label to rc8 and add 5.0.0-rc7, which the PowerShell Gallery has had since 2026-10-10, to the versions that the Gallery has (Docs/Contributing/05-Releasing.md). A separate commit, so that it can be dropped if the changes of this branch go into another prerelease instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: AI Assistant --- NTFSSecurity/NTFSSecurity.psd1 | 2 +- Tests/Repository.Tests.ps1 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NTFSSecurity/NTFSSecurity.psd1 b/NTFSSecurity/NTFSSecurity.psd1 index d00032a..4b32da8 100644 --- a/NTFSSecurity/NTFSSecurity.psd1 +++ b/NTFSSecurity/NTFSSecurity.psd1 @@ -102,7 +102,7 @@ ProjectUri = 'https://github.com/raandree/NTFSSecurity' ReleaseNotes = 'https://github.com/raandree/NTFSSecurity/blob/master/CHANGELOG.md' # Remove the prerelease label for the final release, see Docs/Contributing/05-Releasing.md - Prerelease = 'rc7' + Prerelease = 'rc8' } } } \ No newline at end of file diff --git a/Tests/Repository.Tests.ps1 b/Tests/Repository.Tests.ps1 index 07eeba6..b0efc64 100644 --- a/Tests/Repository.Tests.ps1 +++ b/Tests/Repository.Tests.ps1 @@ -97,7 +97,7 @@ Describe 'Release metadata' { # The PowerShell Gallery doesn't accept a version twice. Add every published version to this list # (Docs/Contributing/05-Releasing.md). It 'Should not reuse a version that the PowerShell Gallery already has' { - $publishedVersions = '4.0', '4.2.2', '4.2.3', '4.2.4', '4.2.5', '4.2.6', '5.0.0-rc1', '5.0.0-rc2', '5.0.0-rc3', '5.0.0-rc4', '5.0.0-rc5', '5.0.0-rc6' + $publishedVersions = '4.0', '4.2.2', '4.2.3', '4.2.4', '4.2.5', '4.2.6', '5.0.0-rc1', '5.0.0-rc2', '5.0.0-rc3', '5.0.0-rc4', '5.0.0-rc5', '5.0.0-rc6', '5.0.0-rc7' $publishedVersions | Should -Not -Contain $version } From 2891fb805bd41bbd70077b9ecb7580f7282a67e5 Mon Sep 17 00:00:00 2001 From: Raimund Andree Date: Tue, 20 Oct 2026 09:39:13 +0000 Subject: [PATCH 4/4] docs(access): say that the warning goes with a calculated result 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 --- CHANGELOG.md | 6 +++--- Docs/Cmdlets/Get-NTFSEffectiveAccess.md | 2 +- NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9fc8653..9b29616 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -221,9 +221,9 @@ The format is based on result looked like an account without any rights. The cmdlet now writes a `GetEffectiveAccessError` with the error that Windows reported and returns no result, as it does when a later step of the calculation fails. - The warning that the result is based on this computer now comes only with - a result; it also came before an error when the computer couldn't be - reached + The warning that the result is based on this computer now comes only when + the cmdlet calculated a result; it also came before an error when the + computer couldn't be reached - Fix `Get-NTFSOwner`, which wrote a "The pipeline has been stopped" error for every path when a command such as `Select-Object -First 1` stopped the pipeline, and which repeated a failed read instead of reporting the diff --git a/Docs/Cmdlets/Get-NTFSEffectiveAccess.md b/Docs/Cmdlets/Get-NTFSEffectiveAccess.md index ae756e0..d64e3ca 100644 --- a/Docs/Cmdlets/Get-NTFSEffectiveAccess.md +++ b/Docs/Cmdlets/Get-NTFSEffectiveAccess.md @@ -188,7 +188,7 @@ Before 5.0.0-rc7, the warning about a computer that couldn't be reached didn't n Before 5.0.0-rc7, a user who wasn't an administrator got the error "Access is denied" and no result on a computer in a domain, also for a name of this computer, such as the default `localhost`. -Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it returns a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached. +Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it calculated a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached. ## RELATED LINKS diff --git a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml index ab38c39..93948b7 100644 --- a/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml +++ b/NTFSSecurity/en-US/NTFSSecurity.dll-Help.xml @@ -5169,7 +5169,7 @@ PS C:\> Get-NTFSAudit -SecurityDescriptor $sd Before 5.0.0, `-ExcludeNoneAccessEntries` had no effect, and the cmdlet returned nothing without `-Path` or for `-SecurityDescriptor`. When the computer of `-ServerName` couldn't be reached, the cmdlet warned that it had calculated the result on this computer, but returned no access instead of that result. Before 5.0.0-rc7, the warning about a computer that couldn't be reached didn't name the computer, and the cmdlet warned for every name of this computer except `localhost` in lowercase, such as `.`, `LOCALHOST`, or the computer name. Before 5.0.0-rc7, a user who wasn't an administrator got the error "Access is denied" and no result on a computer in a domain, also for a name of this computer, such as the default `localhost`. - Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it returns a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached. + Before 5.0.0-rc8, the cmdlet returned no access and no error when Windows refused to start the authorization manager for the computer of `-ServerName`, for example for a name of 32,718 characters or more, so that the result looked like an account without any rights. The cmdlet now writes a non-terminating `GetEffectiveAccessError` with the error that Windows reported and returns no result for the item, as it does for every other failure of the calculation. It warns that the result is based on this computer only when it calculated a result; before 5.0.0-rc8, the warning also came before an error when the computer couldn't be reached.