Can a server-side Web application trigger the creation of thumbs.db files?

A customer had a server-side Web application which creates a large number of image files. The customer was concerned that the system would spend a lot of effort generating thumbnails to be put into the thumbs.db file and wanted to disable the thumbs.db file in order to improve the performance of their Web application. The customer liaison added, "From a brief experiment, it seems that the thumbs.db file is written when a user displays thumbnails on Explorer. Merely creating and copying image files does not trigger the creation of a thumbs.db file. I don't think the customer needs to worry about the overhead of the thumbs.db file since neither the user account of the Web application nor the SYSTEM account will create a thumbnail cache. Is that correct?"

Yes, that's correct.

The thumbs.db file is created by Explorer or any other application that uses Explorer's thumbnail cache. It is unlikely that the customer's Web server is using the Explorer thumbnail cache, so the file won't be created.

To be extra sure, the customer can set the policy User Configuration, Administrative Templates, Windows Components, File Explorer, Turn off the caching of thumbnails in hidden thumbs.db files.

The customer liaison thanked us for confirming what their experimentation revealed.

Comments (9)
  1. Andrea Martinelli says:

    There are a few thumbs.db files on my computer that I know for sure have not been generated by Windows XP.
    Are there any scenarios in which modern versions of Windows store thumbnails in Thumbs.db?

    1. Programs may generate the thumbs.db if they opt into it. For example, the common Save/Open dialog boxes that most programs use will leverage the thumbnail database. I believe Windows Media Player and its associates do as well for album covers.

  2. Joshua says:

    Never underestimate the shenanigans of bad developers. I don’t know an immediate cause but it’s possible they did something so bad with the shell namespace COM components as to cause thumbs.db to generate.

  3. Cesar says:

    I really dislike these files. Windows has Thumbs.db and desktop.ini, MacOS has .DS_Store, even KDE has a “.directory” file it creates when you change the preview settings for a folder (at least it stores the thumbnails in a global per-user cache).

    Of them, in my opinion the Windows ones are the worst ones, since they intrude in the namespace. The other two start with a dot, which clearly separates them from the user-created files, but Thumbs.db sits well in the middle of the namespace.

    And there’s also the obvious privacy leak: create a folder with three images, have Explorer create the Thumbs.db, then delete one of the images and create a ZIP of the whole folder. The Thumbs.db file, sent to your client, can still have the thumbnail for the deleted image.

    1. Piotr says:

      That’s why thumbs.db is marked as hidden – no need to rely on magic names. You have metadata for that. But another valid point is when those are created on network shares. That’s what is really rude.

      1. cheong00 says:

        That’s why “disable thumbnail” and “change to detail view and apply to all folders” are on the list of things I want to do on each system install/reinstall.

    2. I suspect if they implemented this feature today it would be a central store database inside of System Volume Information instead, which would make all kinds of more sense. But I doubt that will happen now simply because what they have works and the cost to reimplement, change existing tests, communicate to customers, etc. would be prohibitively high.

      1. Since Vista, it’s been at %USERPROFILE%\AppData\Local\Iconcache.db, so it’s at least centralized per-user.

        I don’t think adding it to System Volume Information would be a good idea, since that puts it in a protected location, and now you need new APIs to add, retrieve, and erase them, and have an additional unnecessary security risk.

        1. Presumably if one were to reimplement it you could design the APIs appropriate to the implementation. ;-) A user-level datastore makes sense, though, just in the sense that it means you don’t have to worry about tracking permissions for the thumbnails and who’s able to access what. The advantage to using a system-level store is that you can deduplicate the thumbnails generated across all users and cache them within a system service, similar to how the Indexer works.

Comments are closed.

Skip to main content