Difference between revisions of "User:Mjb/Windows folders that can't be renamed or deleted"
(moved content from my workspace) |
(minor updates) |
||
| Line 1: | Line 1: | ||
| − | + | Generally, if a Windows folder can't be renamed or deleted, something is holding open the folder or something in it. | |
| − | Windows generates hidden Thumbs.db files in folders with thumbnail-able content | + | |
| + | Here's one reason that really irritates people: | ||
| + | |||
| + | ==Thumbs.db generation== | ||
| + | Windows generates ''hidden'' Thumbs.db files in folders with thumbnail-able content. As of Windows 7 (maybe Vista, too), the OS doesn't actually need them; the files are only for compatibility with older Windows OSes and apps that make use of the files. | ||
In Windows Vista and Windows 7, there's some kind of Explorer bug which sometimes holds these Thumbs.db files open, preventing renaming or deletion of their parent folder. It seems to mostly affect video files. | In Windows Vista and Windows 7, there's some kind of Explorer bug which sometimes holds these Thumbs.db files open, preventing renaming or deletion of their parent folder. It seems to mostly affect video files. | ||
One workaround is this: | One workaround is this: | ||
| − | * Temporarily change the folder view to one of the following: content, medium icons, large icons, extra-large icons. | + | * Temporarily change the folder view to one of the following: content, medium icons, large icons, extra-large icons. I don't know if this really works every time, though. |
| − | Another workaround is to disable Thumbs.db generation with a group policy update. There are various instructions around for doing this, but this is the simplest (do it as an Administrator, and remember you have to do Run as Administrator when opening the command shell): | + | Another workaround which works 100% for me is to disable Thumbs.db generation with a group policy update. There are various instructions around for doing this, but this is the simplest (do it as an Administrator, and remember you have to do Run as Administrator when opening the command shell): |
* <code>REG ADD "HKCU\Software\Policies\Microsoft\Windows\Explorer" /v "DisableThumbsDBOnNetworkFolders" /t REG_DWORD /d 1 /f</code> | * <code>REG ADD "HKCU\Software\Policies\Microsoft\Windows\Explorer" /v "DisableThumbsDBOnNetworkFolders" /t REG_DWORD /d 1 /f</code> | ||
Revision as of 01:23, 27 March 2013
Generally, if a Windows folder can't be renamed or deleted, something is holding open the folder or something in it.
Here's one reason that really irritates people:
Thumbs.db generation
Windows generates hidden Thumbs.db files in folders with thumbnail-able content. As of Windows 7 (maybe Vista, too), the OS doesn't actually need them; the files are only for compatibility with older Windows OSes and apps that make use of the files.
In Windows Vista and Windows 7, there's some kind of Explorer bug which sometimes holds these Thumbs.db files open, preventing renaming or deletion of their parent folder. It seems to mostly affect video files.
One workaround is this:
- Temporarily change the folder view to one of the following: content, medium icons, large icons, extra-large icons. I don't know if this really works every time, though.
Another workaround which works 100% for me is to disable Thumbs.db generation with a group policy update. There are various instructions around for doing this, but this is the simplest (do it as an Administrator, and remember you have to do Run as Administrator when opening the command shell):
REG ADD "HKCU\Software\Policies\Microsoft\Windows\Explorer" /v "DisableThumbsDBOnNetworkFolders" /t REG_DWORD /d 1 /f
You can then check the status of the key:
REG QUERY "HKCU\Software\Policies\Microsoft\Windows\Explorer" /v "DisableThumbsDBOnNetworkFolders"
After disabling Thumbs.db generation, you might want to just go ahead and delete all your existing Thumbs.db files (do it from the root of each drive):
del /F /S /A:H Thumbs.db
Here are a couple of discussion threads related to this:
One of the posts mentions the possibility that it has something to do with SMB2 Client Redirector cache, but no one seems to have checked into this:
