Add-LinesToFile leaves an empty DACL, denying all access (including git) until repaired

[sharpninja]

Summary

Add-LinesToFile leaves the edited file with an empty DACL (no access-control entries). After the edit, every principal - including the file's owner and git - is denied all data access, surfacing as a confusing Access to the path ... is denied rather than a sharing error. The file is unusable until its ACL is manually repaired.

Environment

• PowerShell.MCP module: 1.11.0
• PowerShell: 7.6.3
• OS: Windows 11 (10.0.26200)

What happened

In a git repo I appended a few lines to .gitignore:

Add-LinesToFile .gitignore -Content $var1   # var1 = the new ignore lines

The cmdlet reported success (Added 6 line(s) to .gitignore), but every subsequent access failed:

• [IO.File]::ReadAllText('.gitignore') -> UnauthorizedAccessException: Access to the path '...\.gitignore' is denied.
• git add .gitignore -> error: open(".gitignore"): Permission denied / fatal: updating files failed
• Show-TextFiles .gitignore -> Access denied

Diagnosis

• Not a sharing lock. The Windows Restart Manager (RmGetList) reported 0 processes locking the file.
• Empty DACL. icacls .gitignore listed no ACEs at all (just the path + "Successfully processed 1 files", with zero permission entries). A sibling file in the same folder was fully accessible.
• Owner was unchanged (the correct user). IsReadOnly was False; attributes were normal (Archive).
• icacls <file> /reset (restoring inherited permissions) immediately fixed it, and the file content was intact - so only the security descriptor was damaged, not the data.

Impact

The file becomes completely inaccessible (reads, writes, and git all fail). In my case it blocked a commit until I diagnosed and repaired the ACL. The misleading "Access denied" (vs. a lock error) makes this hard to diagnose.

Workaround

icacls <file> /reset
icacls <file> /inheritance:e

Likely cause

The write path appears to create/replace the file (or its security descriptor) without preserving the original DACL or re-enabling inheritance - e.g. writing a new file with an explicit empty SD, or a write-to-temp-then-rename that drops the inherited ACL.

Expected

Add-LinesToFile (and the sibling text cmdlets Update-LinesInFile, Update-MatchInFile, Remove-LinesFromFile) should preserve the existing file's ACL and inheritance across edits.

Repro

1. Create a text file in a folder with normal inherited permissions.
2. Add-LinesToFile <file> -Content $var1 (append any lines).
3. icacls <file> -> DACL is empty.
4. Get-Content <file> or git add <file> -> Access denied.

[yotsuda]

Thanks for the careful report — files becoming inaccessible after an edit is exactly the kind of thing I want to get to the bottom of, and your diagnostics gave me a lot to work with.

I tried to reproduce it on a matching setup (Windows 11 26200, PowerShell 7, module 1.11.0). In every path I can exercise I can't get the empty-DACL behavior — but I can't yet construct the mechanism either, so I don't want to treat "I couldn't reproduce it" as proof that nothing happened. Here's what I found, and where I think your own observations actually point.

All four cmdlets write through one atomic-replace helper: File.Replace(temp, target, backup) for existing files, File.Move for new ones. In my tests:

• Existing file (File.Replace): SDDL identical before/after, inheritance still on (AI, not protected), all ACEs preserved.
• New file (File.Move): the destination directory's inheritable ACEs were correctly re-applied.

That matches the documented Win32 behavior — ReplaceFile preserves the replaced file's DACL, and a same-volume move re-evaluates inheritance. And the 3-arg File.Replace we use does not ignore metadata errors, so a failed ACL step would throw rather than silently leave a zero-ACE DACL.

Here's the part I think is telling: your own findings — Restart Manager showing 0 locks, owner and attributes unchanged, file content fully intact, and icacls /reset fixing it instantly — all describe a state where only the security descriptor was altered, with everything the cmdlet actually writes left untouched. That's much more consistent with the DACL being re-stamped after the write (by something else holding WRITE_DAC) than with our write path producing it, since our path either preserves the DACL or fails loudly. An empty deny-all DACL specifically is the signature of something explicitly applying a protected, zero-ACE descriptor — which is not an operation anywhere in this code.

So I don't want to ship the "preserve the existing ACL" change as proposed, because in every case I can reproduce the ACL is already preserved — it wouldn't address what you saw. I'd rather find the real trigger with you. The single most useful thing: if it recurs, capture the broken ACL before the icacls repair:

(Get-Acl <file>).Sddl
(Get-Acl <file>).AreAccessRulesProtected

The SDDL of the broken state would settle it — NULL DACL vs. empty DACL vs. protected-with-orphaned-ACEs each point in a different direction. Two more questions that would help: is $env:TEMP on the same drive as the edited file, and is any AV/EDR/DLP agent or OneDrive/Dropbox sync involved with that folder?

Separately, and regardless of how this resolves: I'm planning to move the temp file into the target file's own directory (the standard atomic-write pattern). That removes the cross-volume File.Replace failure mode and guarantees new files inherit the destination's ACEs on any configuration. I'll be clear that it's robustness hardening, not a claimed fix for your symptom — I don't want to mark this resolved on a change I can't tie to the cause.

[sharpninja]

I've updated my environment to 1.14.0. I'll let you know if this fixes the issue or causes new issues.