Background
I wanted to give a Next.js project folder a new name. It should have been a two-second job, but every attempt ended with Access is denied, even though I had closed every file inside it.
The usual answer is to reboot. I wanted to know what was actually holding it.
What I tried
- Stopped the dev server: still couldn't rename it.
- Closed every editor window: a quick check showed more than ten editor processes still running in the background.
- Force-quit those editor processes: that also stopped another project's dev server running in its terminal, and the rename still failed.
- Checked the files with Windows' own lock check (Restart Manager): it said nothing was locked.
- Installed PowerToys: its install log said the machine was waiting for a reboot.
In the end I kept the old name, but I finally understood what was going on.
Why Windows locks things
Windows makes a different trade-off from macOS and Linux:
- Windows: when a program opens a file, other programs can't delete or rename it unless the first program explicitly allows it. That way nothing swaps out a file a running program depends on.
- macOS and Linux: you can rename or delete a file while it's open, and the program that opened it keeps reading the old contents.
What gets locked is often the folder itself rather than any one file. In a development project the usual suspects are:
- Working directory: once a terminal has cd'd into a folder, the folder can't be renamed.
- File watchers: editors and dev servers watch the whole project, and they can keep running after the window is gone.
- Antivirus scans: Defender scans newly written files, and node_modules holds a lot of them.
- System services: the search indexer and Explorer thumbnails and previews.
The tool that answers the question: File Locksmith
Access is denied tells you something is using the folder, but never what. File Locksmith, one of the small utilities in Microsoft's free PowerToys, answers exactly that.
- Turn it on: open PowerToys and switch on File Locksmith.
- Ask about a file or folder: right-click it in File Explorer, choose Show more options, then Unlock with File Locksmith. You can select several items at once.
- It looks inside folders: for a folder it also checks every file and subfolder in it, which is what my case needed. A check that only looks at single files misses this.
- Read the list: it shows every process using your selection, and each one expands for more detail.
- Release only what's needed: End task stops that one process. The list updates by itself when a process goes away, and Reload scans again.
- See everything: by default it only sees your own programs. If the list is empty but the folder is still locked, choose Restart as administrator to include system services and other users' processes.
There's also a command-line version that can wait until a file is released, which is handy in a build script:
PowerToys.FileLocksmith.CLI.exe --wait --timeout 30000 "C:\path\to\my-project"
If you can't install PowerToys
- Resource Monitor is built in: open it, go to the CPU tab and search for the folder name under Associated Handles.
- Sysinternals handle does the same from the command line:
handle.exe -nobanner my-project
Both list the handles each process holds, folders included. Restart Manager only checks files, which is why it found nothing when the folder itself was locked.
Mistakes I made
- Closing the windows isn't closing the program: with every editor window gone, more than ten processes were still running.
- Force-quitting has side effects: a dev server running in the editor's terminal stops with it.
- Using the wrong tool: a file-only check can't see folder locks, so my "nothing is locked" conclusion was wrong.
- A pending reboot: unfinished system updates make every kind of lock harder to track down.
What improved
Now when a folder won't rename, I right-click it and File Locksmith tells me which program is holding it, instead of me closing apps one by one and guessing. I end just that one process instead of rebooting. And before renaming a project, I close the editor, the dev server and any terminal that's sitting inside it.
Two more ways to avoid it altogether: keep projects on a Windows 11 Dev Drive (or add them to Defender's exclusions), or run Node.js projects inside WSL.
Cover: Closeup padlock wooden door by Markus Spiske, CC0 1.0.
Top comments (0)