Fix ERROR_DIR_NOT_EMPTY (0X00000091) on Windows

Cause #1: Hidden or System Files You Can't See

I know this error is infuriating—you've checked the folder in File Explorer, it looks empty, but Windows refuses to delete it. The most common reason? Hidden files or system files that Windows hides by default. Things like Thumbs.db, desktop.ini, or even a leftover $RECYCLE.BIN folder can lurk there.

Here's the fix: open a command prompt as administrator. Don't use File Explorer for this—it hides stuff. Run:

del /f /s /q /a "C:\path\to\your\folder\*.*"
rmdir /s /q "C:\path\to\your\folder"

The /a flag on del forces deletion of hidden and system files too. If the folder still won't go, try dir /a inside it first to see exactly what's in there:

dir "C:\path\to\your\folder" /a

I've seen desktop.ini cause this error on hundreds of machines—especially on folders you synced with OneDrive or Dropbox. Delete that file manually, then retry.

Real-world trigger: This happens a lot after you move a folder from an external drive. Windows leaves a hidden desktop.ini behind that references the old location. Deleting it first solves the problem 80% of the time.

Cause #2: A Running Program or Open Handle Holding the Folder

Sometimes the folder isn't locked by files—it's locked by a program that has an open handle to anything inside it. Common offenders: Windows Explorer (if you have the folder open in a window), a text editor holding a log file, or antivirus scanning the folder. This tripped me up the first time too—I spent an hour before realizing I had a PowerShell window open with that directory as the working path.

To find the culprit, use Process Explorer from Microsoft Sysinternals (free, no install needed). Run it as admin, hit Ctrl+F, type the folder name, and it'll show you exactly what process has a handle. Kill that process, and you're golden.

No third-party tools? Use PowerShell:

Get-Process | Where-Object { $_.Modules.FileName -like "*yourfolder*" }

Or try the old-school handle.exe from Sysinternals:

handle.exe -accepteula "C:\path\to\your\folder"

Quick workaround: Restart Windows Explorer. Open Task Manager, find "Windows Explorer," right-click, and choose "Restart." This often releases handles from the shell itself.

Real-world trigger: I see this most often with OneDrive or Google Drive—their sync processes sometimes hold a handle on a folder for minutes after you delete the contents. Wait 30 seconds, or kill the sync process in Task Manager.

Cause #3: NTFS Junction Points or Symbolic Links

This one's sneaky. If the folder contains a junction point (like the old My Documents redirect) or a symbolic link, rmdir will fail with ERROR_DIR_NOT_EMPTY because Windows sees the reparse point as a permanent child object. Normal deletion commands don't follow reparse points.

Check if the folder has junctions or symlinks. Open a command prompt and run:

dir /a /s "C:\path\to\your\folder" | find "JUNCTION"
fsutil reparsepoint query "C:\path\to\your\folder\somesubfolder"

If you see JUNCTION listed, you need to remove the link itself first, not just the directory. Use rmdir on the junction point (not del):

rmdir "C:\path\to\your\folder\linkname"

Then delete the parent folder. For symbolic links (not junctions), use rmdir /s and it'll follow the link—but be careful: it'll delete the target too unless you use /s /q and manually exclude the target.

Real-world trigger: Developers and IT pros create junction points to redirect folders like AppData or Downloads to another drive. A clean-up script that doesn't know about them will choke on this error.

Quick-Reference Summary

If none of these work, you're likely dealing with file system corruption. Run chkdsk /f on the drive and try again. And if you're still stuck, boot from a Linux USB—that never cares about hidden files or junctions.