Testably.Abstractions.AccessControl

Implements the methods from FileSystemAclExtensions on the IFileSystem interface so production code that reads or writes ACLs works against both real and mocked file systems.

Installation

.NET CLI

dotnet add package Testably.Abstractions.AccessControl

PackageReference

<PackageReference Include="Testably.Abstractions.AccessControl" Version="7.2.0" />

Central Package Management

Directory.Packages.props

<PackageVersion Include="Testably.Abstractions.AccessControl" Version="7.2.0" />

Project file

<PackageReference Include="Testably.Abstractions.AccessControl" />

Latest version: 7.2.0

The extensions live in the Testably.Abstractions namespace.

What it adds

Extension on	Methods
IDirectory	CreateDirectory(path, DirectorySecurity), GetAccessControl, SetAccessControl
IDirectoryInfo	Create(DirectorySecurity), GetAccessControl, SetAccessControl
IFile	GetAccessControl, SetAccessControl
IFileInfo	GetAccessControl, SetAccessControl
FileSystemStream	GetAccessControl, SetAccessControl

Each GetAccessControl overload accepts an optional AccessControlSections mask, matching the BCL.

IFileSystem fileSystem; // injected

DirectorySecurity acl = fileSystem.Directory.GetAccessControl("archive");
fileSystem.Directory.SetAccessControl("vault", acl);

fileSystem.File.WriteAllText("provenance.txt", "");
FileSecurity fileAcl = fileSystem.File.GetAccessControl("provenance.txt");

Behavior on the mock

On RealFileSystem the calls forward to System.IO.FileSystemAclExtensions. On MockFileSystem the ACL object is stored as metadata via IFileSystemExtensibility and round-tripped: set it, read it back, and it will be the same object.

The mock does not enforce the stored ACL. To simulate denied access, combine the package with MockFileSystem.WithAccessControlStrategy(...).

Windows-only

All ACL APIs are marked [SupportedOSPlatform("windows")]. Calling them on Linux/macOS throws PlatformNotSupportedException.