Why can't I delete a file that is locked or has a too-long path?

What this covers

Being told you cannot delete a file you clearly have the right to delete is one of the more irritating Windows moments. The refusal almost always comes from one of three places: a background program still has the file open, the ACL on the file belongs to an account that no longer exists, or the full path has grown past the ~260-character limit that Explorer and DEL still respect. This guide tells the three apart and clears each one with tools that already ship with Windows.

Symptom

Check whether a process is really holding the file open

Windows refuses to delete a file for at least three different reasons, and each one has a different cure, so identify the cause before you touch anything. This PowerShell check tries to open the file with exclusive access: if it succeeds, no program is holding it and you should be looking at ownership or path length instead. Replace the example path in the command with the full path of the file you cannot delete. If the result says the file IS locked, the exception message usually names the reason — close the application that owns the file (or end it from Task Manager) and retry the deletion before moving on.

$ try {
  $fs = [System.IO.File]::Open('C:\Temp\report.xlsx', 'Open', 'ReadWrite', 'None')
  $fs.Close(); 'File is NOT locked'
} catch { 'File IS locked: ' + $_.Exception.Message }

Take ownership when the answer is 'Access is denied'

Files left behind by an old user profile, a Windows reinstall or a drive moved from another machine keep ACLs that belong to an account which no longer exists, so even an administrator gets refused. This two-part command first makes you the owner of the tree and then grants your account full control over every item inside it — something Explorer's repeated 'Continue' button cannot do in one pass. Point it at the folder that contains the stubborn file rather than at a single file, so nested items are covered too; the placeholder path and the account name in the command must be your own folder and your own username. You will know it worked when deleting no longer asks for permission, or when the lock check from the previous step, run from an elevated prompt, reports that nothing is holding the file.

$ takeown /F "C:\Users\OldProfile\Documents" /R /D Y && icacls "C:\Users\OldProfile\Documents" /grant "%USERNAME%:F" /T

Clear a folder whose path is too long with robocopy

Once the full path passes roughly 260 characters, or a deeply nested folder name confuses Explorer, right-clicking will never remove it — but robocopy happily works with paths beyond that limit. The trick is to mirror an empty folder over the target: robocopy makes the destination match the source, so an empty source means every file and subfolder inside the destination is removed, and the now-empty root can then be deleted normally. Replace the empty-folder path and the target path in the command with your own — the empty directory you just created is the source, and the un-deletable long path is the destination. Success looks like a summary reporting zero directories and zero files copied with a list of deleted items, and a folder that finally disappears from Explorer.

$ mkdir C:\EmptyDir && robocopy C:\EmptyDir "C:\Very\Long\Nested\Path\Folder" /MIR && rmdir /s /q C:\EmptyDir

How to confirm it worked

The file or folder is gone from Explorer and no longer listed by dir, with no error at any point, and re-running the PowerShell lock check finds nothing left to open.

Sources

• FileStream Class
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: FileStream with FileShare.None throws IOException when the file is already open elsewhere, the mechanism behind the lock test.
• File.Open(String, FileMode, FileAccess, FileShare) Method
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: File.Open with FileShare.None throws IOException when another process holds the file open, which is the basis of the lock test.
• takeown | Microsoft Learn
  Microsoft · vendor-doc · 2026-09-17
  Evidence: Microsoft documents takeown /F with /R for recursive ownership and /D Y to answer prompts, making the administrator the file owner.
• icacls | Microsoft Learn
  Microsoft · vendor-doc · 2026-09-17
  Evidence: Microsoft documents icacls /grant with the :F permission and /T for applying the ACE recursively to all files and subfolders.
• robocopy
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: Documents the /MIR switch (mirror a directory tree, deleting destination items not in the source) and handles long paths.
• Robocopy — Robust file copy
  SS64 · technical · 2026-09-17
  Evidence: Describes /MIR as equivalent to /PURGE plus /E — mirroring an empty folder deletes everything under the target path.

Last verified: 2026-09-22

Related guides