guidox / PC
Read the ACL with **icacls** and the owner with **Get-Acl**, check the attributes, then take ownership with **takeown /f /a** and remove the denying entry with **icacls /remove:d**.
The message names the reason: access denied is a permission, being in use is a lock. The read-only and system attributes block a delete on their own.
$f = 'C:\ProgramData\Vendor\cache.db'
Get-Item $f -Force | Select-Object Name,Attributes,Length,LastWriteTime
Get-ItemProperty $f -ErrorAction SilentlyContinue | Select-Object * -ExcludeProperty PS*
attrib "C:\ProgramData\Vendor\cache.db"**icacls** prints allow and deny entries separately. A deny for the current user beats every allow, which is why adding permissions sometimes changes nothing.
icacls "C:\ProgramData\Vendor\cache.db"
(Get-Acl 'C:\ProgramData\Vendor\cache.db').Access | Select-Object IdentityReference,FileSystemRights,AccessControlType,IsInherited
(Get-Acl 'C:\ProgramData\Vendor\cache.db').OwnerA read-only or system file cannot be deleted by a normal call. Removing the attributes costs one command and eliminates the simplest cause.
attrib -R -S -H "C:\ProgramData\Vendor\cache.db"
Set-ItemProperty 'C:\ProgramData\Vendor\cache.db' -Name Attributes -Value 'Normal' -ErrorAction SilentlyContinue
(Get-Item 'C:\ProgramData\Vendor\cache.db' -Force).Attributes**takeown /a** gives the administrators group ownership. A file owned by TrustedInstaller needs this step before any ACL change succeeds.
takeown /F "C:\ProgramData\Vendor\cache.db" /A
takeown /F "C:\ProgramData\Vendor" /R /A /D Y
(Get-Acl 'C:\ProgramData\Vendor\cache.db').Owner**/remove:d** deletes the denying entry instead of fighting it. Only then does an allow entry have an effect on the delete.
icacls "C:\ProgramData\Vendor\cache.db" /remove:d "$env:USERNAME"
icacls "C:\ProgramData\Vendor\cache.db" /grant "$env:USERNAME:F"
icacls "C:\ProgramData\Vendor\cache.db"A file that returns after a delete is recreated by a running service. Stopping that service is the actual fix, not a stronger permission.
Remove-Item "C:\ProgramData\Vendor\cache.db" -Force
Test-Path "C:\ProgramData\Vendor\cache.db"
Get-Service | Where-Object Name -match 'vendor' | Select-Object Name,Status
Start-Sleep -Seconds 30
Test-Path "C:\ProgramData\Vendor\cache.db"A process holds a handle. Find it with Resource Monitor or handle64.exe, close the process, then delete.
Ownership was not taken, or the file is on a read-only volume. Run takeown first and check the volume's write state.
A service or a scheduled task recreates it. Stop the service, delete the file, then decide whether it should be excluded from the app.
Use the \\?\ prefix or delete from the deepest folder upwards with PowerShell.
For a cache or a leftover installer, yes. For a file in WinSxS or System32, no: the component store protects itself for a reason.
Yes. Deny is evaluated before allow, which is why people add permissions with no effect.
Yes, after taking ownership as an administrator. The owning account does not lock the file by itself.
Restore the previous owner with icacls /setowner, re-add the deny entry you removed if it was deliberate, and set the attributes back with attrib +R.
Free · no account needed · tracks your progress