locked
Fix bug Thumbs.db: "The action can't be completed because the file is open in Windows Explorer"

    Question

  • This problem is just about "bad design" (i.e. uncorrected application-level bug) and maintaining a bad user experience for files and folders - which will include Storage Spaces under the hood? Or?


    Why is it that Windows is still incapable of unlocking this "all over the file system using out-of-the-box factory settings" thumbs.db file?


    Especially when all it may take is some simple discovery that the concrete thumbs.db file is part of a move folder operation and should be unlocked. How difficult can it be to fix that?


    It just takes the transparency away of using the file and storage system in Windows - i.e. reminds you that the overall user experience is still weak (unacceptable) - because when you move files - it's often a set of repeated operations - so you're very likely to have this bad experience with "Windows conflicting and having an unresolved race condition with itself" - and waiting for a TIMEOUT to finally resolve this "unresolved" situation … (i.e. oldies goldies of locks and race conditions)


    Regards,
    Computermensch




    More details:
    --------------

    Just readying my setup for BYOD decoupling disks and stuff - including setting up more experimentation with storage spaces.
    However, that "migration" in my case involved some relocation of files and folders - BTW a lot of it.

    So I just could not help noticing that the "thumbs.db" less-user-friendly annoyance - in particular disturbing any work with files and folders - is still there:


    Thumbs.db: "The action can't be completed because the file is open in Windows Explorer"


    I got that message so many times during the work above - must be 100's of times - and I just had that dialogue - sometimes a modal window sometimes not - but in any case blocking work.


    Can't you fix that? When moving files and folders around - you often take a peek inside that folder. "Chanches" are (like a 50% gut-feeling ...) Windows will lock up that thumbs.db file - and you doesn't have to be in any particular folder view (like Large Icons) in Explorer before that happens. It just happens.


    Very annoying like bloat-stuff (non-workable) that thumbs.db screws simple file movements up - and you need to wait for a timeout in Windows to release that file - practically waiting for the modal window to become usable … or you can later go back to the source to "help" Windows move the rest of those files.


    Everybody has a lot of disks today … and may be they are supposed to look forward to Storage Spaces?
    But discovering that the new Windows 8 still has those problems using files and folders on top of storage spaces is likely to take some of the joy away.


    So why haven't you fixed that? Why should it still be difficult to move files and folders in Windows 8 (doesn't work 100% - more like 70-80% at best) (no problem in my case - but probably a problem for consumers … take your bet)?


    BTW Using the Consumer Preview - but may be you fixed it for Release Preview? Probably not - but this stuff is actually what drives consumers to software and web services that are easier to consume. For starters it has to work … without knowing about "known bugs and problems".


    So fix this kind of stuff with files and folders - or storage spaces will not bring anything new to consumers (non-expert users) underlying stuff in file system operations that does not work - ready to consume - like in the case with some "thumbs.db Windows system file that is locked by Windows itself (Explorer) - and blocks what the user wants to do … just move a folder??"


    In case of software guess I am not a consumer - but I also "dislike very much" having to hit that "try again" button (while expert users know Windows has blocked the file operation). Consumers just know it does not work ...













    Sunday, June 03, 2012 5:16 PM

Answers

All replies

  • the thumbs.db is no longer used by Windows since Vista. The thumbnails are now stored in large files in the folder

    C:\Users\Andre\AppData\Local\Microsoft\Windows\Explorer


    "A programmer is just a tool which converts caffeine into code"

    Sunday, June 03, 2012 6:26 PM
    Answerer
  • the thumbs.db is no longer used by Windows since Vista. The thumbnails are now stored in large files in the folder

    C:\Users\Andre\AppData\Local\Microsoft\Windows\Explorer

    again, you don't have the required knowledge to understand this. Thumbs.db is still used for network paths: http://support.microsoft.com/kb/2025703
    Monday, June 04, 2012 3:21 AM
  • Ok


    Thanks to both of you for your answers and the link to the support article.


    … and it made me think thumbs.db is still in use not properly understanding how the shell system now works (has worked for several years) … just because I use the network for files (many do and will experience this problem ...)


    Guess MS should remember to disable the thumbs.db system complete in Windows 8 … thus still a bug carrying support article kb2025703.



    Tuesday, June 05, 2012 12:29 PM
  • Hi,

    I already recorded your finding.

    Thanks for your report.


    Juke Chou

    TechNet Community Support

    Wednesday, June 06, 2012 7:37 AM
    Moderator
  • ok, I always set this group policies for years. Thanks ;)


    "A programmer is just a tool which converts caffeine into code"

    Wednesday, June 06, 2012 8:16 AM
    Answerer
  • Was anything changed in Windows 8 to fix this problem: http://support.microsoft.com/kb/2025703?

    "The folder rename operation fails because thumbcache.dll still has an open handle to the local thumbs.db file and does not currently implement a mechanism to release the handle to the file in a more dynamic and timely fashion."

    This apparently also concerns how IThumbnailProvider works from 3rd parties in managed code. I.e. if we're running a PDF thumbnail provider in Windows - we'll get the experience of a "lock up" (really a blocking wait in the scheduling ...) if it was written in managed code (i.e. .NET) - if a networked file system is used. Meaning any business users are likely to experience that (unless we disable the caching on networked file systems according to support article kb2025703)

    Down below is a Microsoft quote from a blog:

    ... this problem only occurs on Windows 7, I looked at the implementation of the code that handles calling the thumbnail provider on Windows 7 versus Windows Vista. The main difference is that in Windows Vista, the thread that handles calling the thumbnail provider exits almost immediately after calling the thumbnail provider. While the IStream is orphaned on Windows Vista when the dllhost.exe process terminates, the problem appears to not exist because the orphaned IStream is cleaned up when the thread exits. On Windows 7, the thread that calls the thumbnail provider waits for a period of time to see if there is any other work to be performed. The thread terminates after a period of time if there is no other work to be performed.

    That said, our recommendation is that you implement your thumbnail provider using unmanaged code. Please let me know if you have any additional questions.

    (... however, writing ones own provider in unmanaged code wont help, since if the user dumps a jpg or a video file into that networked folder he'll experience the lockup anyway since the built in providers seem to be in managed code anyway)


    Wednesday, August 29, 2012 6:24 AM
  • I can add I've checked out a number of 3rd party addons - and not just free, but commercial including from MS Partners, i.e. FastPictureViewer Codec Pack, that actually resets (enables) thumbs.db on remote shares (process monitor). If managed code was used, they will reenable "the blocking" on the local machine.

    I was looking for PSD and PDF thumbnail providers - but not just that. Also the "correct" (most optimal) system configuration given the prerequisites like the support article and the inner workings of Explorer in the Win7 releases.

    So that's the reason to pop the question - allthough I guess I could just test it: Has this been changed in Windows 8?: On Windows 7, the thread that calls the thumbnail provider waits for a period of time to see if there is any other work to be performed. The thread terminates after a period of time if there is no other work to be performed.


    Wednesday, August 29, 2012 6:43 AM
  • Actually, for some reason in Windows 8, thumbs.db files in the folders of the images ARE being used once again. I have watched Windows 8 create them numerous times so I know what I am talking about.

    Someone must have thought that it was a good idea to have thumbs.db files again, even though numerous people told Microsoft that it was not a good idea.

    Sunday, September 09, 2012 1:24 AM
  • Ah, this is a "To Work" option:  Disable the generation of thumbs.db files via the Local Group Policy Editor and your problems will be resolved.  They are only generated for compatibility with outdated applications, and are most certainly NOT needed for Windows operation.

    > User Configuration
     > Administrative Templates
      > Windows Components
       > File Explorer

       

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options


    • Edited by Noel Carboni Sunday, September 09, 2012 3:53 PM typo
    Sunday, September 09, 2012 3:50 PM
  • I'm hitting something similar in Win8RTM, but I don't even understand why it's happening.  On a fresh boot, I'm trying to delete a local folder (not network) that I have not even gone into during the current boot cycle, I'm hitting that Thumbs.db is in use.  Totally perplexing...


    Mark

    EDIT: after traversing into one of the folders (there were two with this error) with Explorer, then backing out, the lock freed up allowing deletion.  To verify, I did it again on the second one, and it too then deleted OK.

    EDIT2: I have run into this again.  really annoying.  I have 10 folders, simply trying to delete them all, all 10 have this problem with Thumbs.db locked.  If I open a folder and back out of it (as in EDIT above), I can delete the file.  However, if I open each, then back out, then attempt to delete them all, they all remain locked!  I have to do each one separately.  Go in, go out, delete, rinse repeat.

    • Edited by mpietras Monday, October 15, 2012 3:20 PM EDIT2
    Monday, October 08, 2012 2:06 PM
  • I still have this problem and i am using Win8 professional, i cant delete any folder....ill simply disable it......
    Monday, October 08, 2012 9:53 PM
  • I have this problem too in Windows 8 Pro. Please fix this. Makes it really annoying to work with!
    Tuesday, November 06, 2012 4:44 AM
  • Do you people ever actually read the thread to which you attach a "me too" note?  The solution is right up there.  Is running the Group Policy Editor just too geeky for you?

      

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Tuesday, November 06, 2012 5:29 PM
  • I don't think I should have to edit my group policy just to work around a problem in the OS.  It's a known issue and should be corrected.
    Wednesday, November 07, 2012 3:16 PM
  • It's not a workaround, it IS the correction.

    Thumbs.db is only created out of Windows not wanting to make itself actively incompatible with a few ancient applications that expected to see that file there.  Chances are extremely good that you don't actually HAVE those applications, so the Thumbs.db file is being created (and causing you problems) for no reason at all.

    Microsoft re-implemented thumbnail caching long ago but left this setting turned on.  It's been high time to turn it off for a few major releases now.  You will lose no Explorer functionality by turning it off - honest!

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options


    • Edited by Noel Carboni Wednesday, November 07, 2012 8:03 PM
    Wednesday, November 07, 2012 7:58 PM
  • Except there are no such options in gpedit.msc in Windows 8.

    Under user configuration there is:

    Software settings
    Windows settings
    Administrative templates

    Neither of which has any "Disable the generation of thumbs.db" in any submenu.


    • Edited by Tobias Solem Saturday, November 17, 2012 12:05 AM
    Saturday, November 17, 2012 12:03 AM
  • Oops, I'm sorry, I omitted the actual name of the entry (the bolded text was just telling you what to do).  I think I copied that from another post and omitted the name of the entry.  Here's where it is and what it's called, exactly:

     

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options

    Saturday, November 17, 2012 2:16 AM
  • This finally solved my problem. Thanks, everyone who contributed! If you, like myself, had a hard time getting to the group policy editor, just do a search for "gpedit.msc" in the Start screen.

    I think this is a tacky solution for the Thumbs.db problem. Not every Win8 user knows to check the Microsoft forums, and not every user has the knowledge, patience, or confidence to go into such technical details to modify the way their system operates.

    Win8 does not "Work out of the box" as it should.

    Wednesday, November 21, 2012 10:37 PM
  • Hi Noel.

    Can you please indicate, if there's one,  the registry key to work on to change this value (caching thumbs...) . Win 8 home edition, which I'm running, is not equipped with GPE, or, at least I can't find it...

    I found this for 7 could it be used as well?

    Windows Registry Editor Version 5.00
    
    [HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\Explorer]
    "DisableThumbsDBOnNetworkFolders"=dword:00000001

    many many thanks. 

     Is running the Group Policy Editor just too geeky for you?

    mmm...I guess so.

    (i'm having problem with fonts)


    Thursday, March 14, 2013 4:30 PM
  • It's not a workaround, it IS the correction.

    Thumbs.db is only created out of Windows not wanting to make itself actively incompatible with a few ancient applications that expected to see that file there.  Chances are extremely good that you don't actually HAVE those applications, so the Thumbs.db file is being created (and causing you problems) for no reason at all.

    Microsoft re-implemented thumbnail caching long ago but left this setting turned on.  It's been high time to turn it off for a few major releases now.  You will lose no Explorer functionality by turning it off - honest!

     

    -Noel



    Hi,

    IMHO, it's a workaround. The question is not about the reason to generate that file or not, but why it's left open by windows explorer and why windows explorer itself is not able to close it when I want to delete its folder.

    This IS a bug, and an annoying one...

    P.S. : sorry if my english is not clear.

    Andrea

    Monday, April 15, 2013 12:51 PM
  • This time it really is more like a fix.  The fix is to disable a workaround to some long-past compatibility issue.

    Explorer has the file open because it's generating Thumbs.db files that no application needs today. 

    Turning off that useless compatibility workaround code, WHICH ISN'T NEEDED FOR ANYTHING, is the fix.

    You could argue that the setting being enabled by default - causing old junk Explorer code to run - is a bug, and you're actually right.

    I'm guessing that, at the time the thumbnails Explorer actually USES were moved to central database files (was that Vista?), Microsoft didn't just turn off Thumbs.db generation wholesale because they were concerned about maintaining compatibility with some application that used them, or other older systems on a network.  I suspect they intended to make the default policy for new installations to be off at some point, but probably the people responsible for remembering to do that moved on, and no one remaining at Microsoft ever thought to do it.  Maybe we should blame the folks still hanging desperately on to XP.  :)

    In any case, Microsoft isn't listening, so invoke the fix or workaround or WHATEVER you want to call it and be happy.  There's no downside I've ever found.

    And yes, I believe the registry key Davide identified above is the correct one to tweak if you don't have the group policy editor.

     

    -Noel


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options



    • Edited by Noel Carboni Tuesday, April 16, 2013 1:34 AM clarified wording
    Tuesday, April 16, 2013 12:33 AM