Why a File Is 'In Use' and Won't Delete (And How to Fix It)

"The action can't be completed because the file is open in another program." It is one of the most familiar messages in Windows, and the advice you find is usually "reboot" — which works but tells you nothing. This page explains why the lock exists, how to identify the exact process holding it in under a minute, and why the same operation never fails on Linux or macOS.

The fastest fix

Open Resource Monitor (type resmon into Start), go to the CPU tab, and type the filename into the Associated Handles search box. It names the exact process. Close that program normally and the file releases. No reboot and no third-party software.

Why the lock exists at all

This is not a bug or a Windows quirk to be worked around. It is a deliberate design decision, and it differs fundamentally from how Unix systems work.

Windows: mandatory locking

When a Windows program opens a file, it declares what it will allow others to do — through a parameter called the share mode. A program can permit others to read, to write, to delete, or none of those. If it does not grant delete permission, the kernel refuses every deletion attempt from anyone, including an administrator.

Crucially, the kernel enforces this. There is no way for another program to ignore it. That is what "mandatory" means, and it is why the error is absolute rather than advisory.

Unix: the filename is not the file

Linux and macOS separate two things Windows treats as one. A file's data lives in an inode; a filename is merely a directory entry pointing at that inode. Deleting a file calls unlink(), which removes the name. The inode — and the data — survive as long as any process still has it open, and are freed only when the last handle closes.

# On Linux this always succeeds, even mid-write
rm /var/log/huge.log

# The name is gone. The data is not — the writing process
# still holds an open handle to the now-nameless inode
# and continues writing to it.

df -h        # disk still full
ls /var/log  # file no longer listed
                

💡 The classic Linux disk-space trap

An administrator deletes a huge log file to free space, and df reports the disk is still full while du shows nothing large. The data belongs to a deleted file that a running process still holds open. Find it with lsof | grep deleted. The correct fix is to empty the file rather than remove it:

truncate -s 0 /var/log/huge.log
# or
: > /var/log/huge.log

# Find the culprits
lsof +L1
                    

Neither model is simply better. Windows locking prevents a file being pulled out from under a running program — which is why you cannot delete a DLL an application is executing from. Unix's approach makes updates atomic and deletion always possible, at the cost of the surprising disk-space behaviour above. Windows has since added POSIX-style delete semantics, but decades of applications do not request it.

Finding the process — three methods

Resource Monitor (built in, no install)

Press Win + R, type resmon, press Enter.
Go to the CPU tab.
Expand Associated Handles.
Type the filename — or part of it — into the search box.

Every process holding the file appears. You can right-click and choose End Process directly, though closing the application normally is safer where possible.

Handle, from Microsoft Sysinternals

# Which process has this file open?
handle64.exe "C:\path\to\file.pdf"

# Everything a process has open
handle64.exe -p notepad.exe

# Close a specific handle by ID — powerful and risky
handle64.exe -c 1A4 -p 4820
                

handle -c forcibly closes a handle without the owning process knowing. The program keeps a file descriptor it believes is valid, and the next write can fail or corrupt data. It is genuinely useful when nothing else works and genuinely dangerous on anything holding unsaved state.

PowerShell

# Test whether a file is locked without changing anything
function Test-FileLock {
    param([string]$Path)
    try {
        $s = [System.IO.File]::Open($Path, 'Open', 'ReadWrite', 'None')
        $s.Close()
        return $false
    } catch { return $true }
}

Test-FileLock "C:\temp\report.xlsx"

# Which processes have a folder open?
Get-Process | Where-Object { $_.Path -like "*\MyFolder\*" }
                

The usual culprits

Holding the file	Why	Fix
Windows Explorer	The preview pane and thumbnail generator open files to render them, and do not always release promptly	Turn off the preview pane (`Alt` + `P`), navigate away, or restart `explorer.exe`
Antivirus	Real-time scanning opens every file that changes	Wait a few seconds; scans usually finish quickly
Windows Search indexer	Reads document contents to build the index	Wait, or exclude the folder from indexing
Cloud sync clients	OneDrive, Dropbox and Drive open files to upload or hydrate them	Pause syncing until the operation completes
An app you closed	The window closed; the process did not exit	Check Task Manager and the system tray
A mapped network drive	A stale SMB session on the server side	`net use * /delete`, or ask an admin to close the session
A running executable or DLL	Windows locks binaries while they are being executed	The program must be stopped — this lock is not bypassable

⚠️ Restart Explorer instead of rebooting

When Explorer itself holds the lock, restarting just that process takes two seconds and does not close anything else. In Task Manager, find Windows Explorer, right-click, and choose Restart. Your desktop and taskbar disappear briefly and come back; every open application is unaffected.

When the message is misleading

Windows reports several different problems with the same "in use" wording. If no process holds the file, the cause is one of these.

Permissions rather than locking

# Inspect the current permissions
icacls "C:\path\to\file"

# Take ownership, then grant yourself full control
takeown /f "C:\path\to\file"
icacls "C:\path\to\file" /grant "%USERNAME%:F"

# For an entire folder tree
takeown /f "C:\path\to\folder" /r /d y
icacls "C:\path\to\folder" /grant "%USERNAME%:F" /t
                

This is common with files copied from another machine or restored from a backup, where the security descriptor still references a user account that does not exist locally.

Path length

Windows historically limited paths to 260 characters. Deeply nested folders — typically from an extracted archive or a JavaScript project's dependencies — exceed it, and the resulting error is often reported as the file being inaccessible rather than the path being too long.

# The \\?\ prefix bypasses the 260-character limit
Remove-Item -LiteralPath "\\?\C:\very\deep\path\file.txt" -Force

# robocopy mirroring an empty folder deletes anything, at any depth
mkdir C:\empty
robocopy C:\empty C:\stubborn-folder /MIR
rmdir C:\empty
rmdir C:\stubborn-folder
                

That robocopy technique is the most reliable way to remove a deeply nested folder tree. It is also dramatically faster than Explorer for folders containing many thousands of files.

Invalid characters or reserved names

Files created by a Unix system, or by a badly written program, can carry names Windows considers illegal — a trailing space or dot, or one of the reserved device names CON, PRN, AUX, NUL, COM1 through COM9, LPT1 through LPT9. Explorer cannot address them at all.

# The \\?\ prefix disables name parsing, so these become reachable
del "\\?\C:\path\to\file "
del "\\?\C:\path\CON"
                

The order to try things

Close the obvious application and check the system tray for a still-running instance.
Identify the holder with Resource Monitor. This is the step most people skip, and it usually answers the question outright.
Restart Windows Explorer if Explorer is the holder.
Pause cloud sync and antivirus briefly if either appears.
Check permissions with icacls if no process holds it.
Try the \\?\ prefix for long paths or illegal names.
Boot into Safe Mode — most third-party software does not load, so almost nothing holds locks.
Force-close the handle with handle -c only as a last resort, and never on a database or a file being written.

🚨 Be sceptical of "unlocker" utilities

The search results for this problem are dominated by free unlocker tools, and this category has a long history of bundled adware and worse. Everything they do is achievable with Resource Monitor, which is already installed, or Sysinternals Handle, which comes from Microsoft. There is no capability worth the risk.

Avoiding it in your own software

If you write code that touches files, a few habits prevent your program becoming someone else's locked file:

Open with a permissive share mode. Reading a file should not stop others deleting it. In .NET that means passing FileShare.ReadWrite | FileShare.Delete.
Close handles deterministically. Use using, with, defer or try-with-resources rather than waiting for a garbage collector.
Write to a temporary file and rename. Renaming over the target is atomic, so a reader sees either the old file or the new one and never a half-written one.
Hold the file for as short a time as possible. Read the contents into memory, close it, then work.

// Atomic write pattern — safe in every language
1. Write everything to file.tmp
2. Flush and close file.tmp
3. Rename file.tmp → file.txt   // atomic on every OS

// A crash at any point leaves either the complete old
// file or the complete new one — never a corrupt hybrid.
                

Working with files in the browser instead?

Convert, compress and combine files without them ever leaving your device — no upload, no temporary server copy, no lock.

Browse all tools →

Summary

Windows enforces file locks in the kernel. No tool can bypass a lock; it can only close the handle behind the owner's back.
Resource Monitor names the process in seconds. Identify before you force anything.
Explorer's preview pane is a frequent and invisible culprit. Restarting Explorer is faster than rebooting.
Unix separates names from data, so deletion always succeeds — and disk space is only reclaimed when the last handle closes.
"In use" sometimes means permissions, a long path, or an illegal filename. The \\?\ prefix handles the last two.
Skip the unlocker downloads. Everything they do is built in or comes from Microsoft.

Frequently Asked Questions

How do I find out which program is using a file?

Open Resource Monitor, go to the CPU tab, and type the filename into the Associated Handles search box — it names every process holding the file. Microsoft's free Handle utility does the same from the command line with 'handle64 filename'. Both are far more reliable than guessing which application to close.

Why can Linux delete a file that is open but Windows cannot?

They use different locking models. Windows uses mandatory locking enforced by the kernel — an open file cannot be deleted or renamed. Unix systems separate the filename from the data: deleting removes the name, while the data survives until the last program using it closes. So on Linux the delete succeeds immediately and the disk space is reclaimed later.

Is it safe to force delete a locked file?

It depends what is holding it. Force-closing a handle belonging to a document editor or media player is generally harmless. Doing it to a database file, a system process, or anything mid-write can corrupt data. Identify the process first — if it is something you recognise and can close normally, always do that instead.

Why does a file stay locked after I close the program?

Usually the process did not fully exit. Applications with background updaters or tray icons often keep running after the window closes. Windows Explorer itself is another common culprit: the preview pane and thumbnail generator open files to render them and can hold the handle after you have navigated away.

Why does deleting a log file on Linux not free up disk space?

Because the data is only released when the last open handle closes. If a running service still has the log open, deleting the file removes its name but the service keeps writing to the now-nameless data, which still occupies disk. The fix is to truncate it instead — 'truncate -s 0 file.log' — or restart the service.

Written by Paras

We build free, browser-based file tools and write the reference material we wish existed when we were looking things up. Spotted an error? Tell us and we will fix it.

Why Windows Says a File Is 'In Use' — And How to Actually Fix It