Unable to delete thumbs.db

Hi ridil, I am Paulo and I'd like to help.

Thumbs.db is created to display thumbnails. If you want to delete the folder, you should be able to do that by disabling thumbnails first. In File explorer, click on View tab > Options. In the resulting window, click the View tab and then check "Always show icons, never thumbnails". Apply and OK and you should now be able to delete the folder.

I had this same problem. The fix was to rename the Thumbs.db file to Thumbs.dat. Once it was renamed, I was able to delete the file and the folder it was in.

I'm not sure what caused the Thumbs.db file to suddenly appear in our folders. The solution is not elegant, but it worked for us.

Try to disable the showing of system files. Go to the Folder Options window once again and then in the View tab, check the option "Hide protected operating system files (Recommended)". Apply and OK. Check if you'll be able to delete it now.

If it doesn't work then the only option is to temporarily turn off thumbnails so you can delete the folder. Once deleted, you can turn it on again. Since Windows is constantly caching the thumbnails, the file is being used all the time so the only way is to disable it so it won't generate a cache.

Hi Sabya

I appreciate the help.

I'm looking for something faster and less intrusive than having to reboot or even having to boot into safe mode.

Is there a proper way to delete those folders which doesn't involve hacking the registry, changing system wide settings, booting from a linux live cd or killing explorer.exe? After all their empty so i don't understand why there's the need to hold on to a thumbs.db which by then shouldn't contain any thumbs. Maybe there's a purge-unused-thumbs option somewhere?

There are already easier hacks, like

I'm often succeeding with restarting explorer.exe from the taskmanager's app tab (wondering why explorer.exe is the only process offering "restart" in its context menu) and then being quick enough to delete such folders before explorer grabs em again. But there are always some hard ones which somehow escape this hack.

For such the only working thing i know of is to actually end all explorer.exe processes, delete the folder from a cmd line with rmdir /S/Q "foldername" and restart explorer.exe.

but i'm looking for a proper handling or at least a consistent explanation.

What Paolo suggested seemed reasonable and intuitive to me and would also cover what you describe as "The file is being used by the system so it cannot be removed at that instant of time"

Try to disable the showing of system files. Go to the Folder Options window once again and then in the View tab, check the option "Hide protected operating system files (Recommended)". Apply and OK. Check if you'll be able to delete it now.

If it doesn't work then the only option is to temporarily turn off thumbnails so you can delete the folder. Once deleted, you can turn it on again. Since Windows is constantly caching the thumbnails, the file is being used all the time so the only way is to disable it so it won't generate a cache.

but even that doesn't seem to convince explorer.exe to let go of the handles.

I strongly feel like there must be a proper solution because what sense does it make to keep a thumbs.db database for an empty folder. Otherwise this clearly smells like a bug and i'm having this problem for ages, and apparently thousands of other people too so it's hard to believe that MS didn't take the time to do something about it.

Maybe there is some sort of purge option which convinces explorer.exe to go through all its open handles and, if thumbnails are turned off, let go of those handles for good?

Hi Paulo

Your suggestion is a system wide change and not just for a particular folder, right?

I'd like to have thumbnails turned on.

Is the only solution to temporary turn em off before deleting thumbs.db and then turn em on again?

I don't understand where there's a thumbs.db in an empty folder in the first place. Shouldn't it be automatically deleted or at least not be kept alive with an open file handle in this case?