Why don’t per-item custom icons work when I open a Zip file or some other virtual folder?

A customer observed that when they opened a Zip file containing an Excel spreadsheet saved as XML, the icon for the spreadsheet in the Zip folder is just a plain XML icon rather than a fancy Excel-XML icon. "Is there any way to invoke a shell icon handler on an item inside a Zip folder?"

Even if there were a way, you wouldn't like it.

Think about it: In order to determine whether the XML file should get a plain-XML icon or an Excel-XML icon, the Office icon handler needs to open the XML file and sniff around to see if has whatever it is that makes an XML file an Excel-XML file.

This means that the Zip folder has to extract the file so that the icon handler can sniff it.

This means that opening a Zip folder would result in decompressing every file in it just so that it can give the decompressed file to the icon handler so the icon handler can say what icon to show.

You probably wouldn't like that.

Therefore, Zip folders do not use icon handlers to obtain icons for items inside Zip files. It just uses the generic icon for the file extension.

Comments (19)
  1. alegr1 says:

    Well, it's good that the icon handlers at least peek into the "real" files. I can only imagine how much resistance this feature met, because, heaven forbid, what if the files are in the offline storage and have to be brought back!

  2. Antonio Rodríguez says:

    This is one of those "you-can-figure-it-for-yourself" questions.

  3. EduardoS says:

    Ok, not showing XML-Excel icon inside Zip files is acceptable, frankly, I would be fine if those icons didn't exists at all!

    But technically it is not that hard, while the zip format is far from perfect it allows for decompression of individual files and, if the Office icon handle just need the start of the file to identify and XML-Excel then it can stop decompression just after identification.

  4. Mathieu Garstecki says:

    @Simon: that's if you assume every icon handler is well behaved and will not try and load the whole file. Or maybe some handler does need data at the end of the file to make its choice.

    @alegr1: I haven't checked, but maybe Explorer uses the generic icon for offline files too ?

    [It also assumes that icon extractors never need to seek (since virtual streams are not seekable in general). And as you noted, many file types put the interesting information at or near the end (MP3, EXE). And yes, Explorer ignores icon handlers for offline files and shows the generic icon. -Raymond]
  5. Adam Rosenfield says:

    It's a good thing that zip files (unlike compressed tarballs) have the property that individual files can be decompressed without needing to read the entire archive, so that if Explorer did want to sniff certain files (say, all .xml files), it could reasonably do so.

    @alegr1: Hah, nice one.

  6. Gabe says:

    And if it did decompress files to show the icons, the question would instead become "How come per-item custom icons only work in Zip files that don't have passwords?" or "How come I have to provide a password just to look at the list of files in a Zip archive?".

  7. Joshua says:

    I often wonder if it was a mistake to show the custom icon when accessing an EXE directly rather than through its shortcut, but that's a different story.

  8. Skyborne says:

    And if you're going to auto-decompress files to get the icon, you also risk someone sending you a zip bomb.

  9. Rob says:

    @Joshua: That's a relatively low-cost operation.  Icons for EXEs are stored in a specific section which is quickly locatable based on the PE file definition.  (If they're PE files, anyway).

  10. @Rob: Joshua probably mean security problems — with custom icons EXE files can pretend that they are files of other types or directories.

  11. SimonRev says:

    @Macrosofter — the real security issue happened whenever Microsoft decided that the default should be to hide file extensions.  It is pretty obvious if you see the .exe on the end of the filename.

  12. chentiangemalc says:

    @SimonRev How is this a security issue? The default explorer view also tells you these are type 'Application' That might be more obvious than .exe to non-tech person. Not to mention situation where you have something like naked.jpg                                            .exe and the .exe part might not visible. You could go MacOS finder style which shows you beginning & end of filenames where there is not enough space, but I'm not convinced that is necessarily better.

  13. Simon Buchan says:

    Well, it's not terribly costly to decompress the first 1k or so of the files in the folder you're viewing, so it's not a *technical* reason this isn't possible, just an engineering and cost/benefit one. I'm remembering something about Explorer using COM interfaces to navigate and read virtual (and probably physical?) folders and sniff their content, so I'm guessing this may even be possible to do as an extension, but what do I know about Windows?

    [Right. But the number of icon extractors that know how to read virtual content is zero, to within experimental accuracy. And other container formats may not be so easy to create invididual virtual streams from. (Try it for an FTP folder!) -Raymond]
  14. 640k says:

    It is a security vulnerability whenever extension!=content. In those cases you can't trust explorer.

    And it wouldn't be impossible to create a cache featuer/component/service which displayed the right icons after the user had extracted the files. Why not try to do the right thing instead of finding corner cases?

  15. alegr1 says:

    I wish there was a central cache of icons, and explorer didn't have to re-read them every darn time you log in. Use Last-Modified timestamp or some more reliable modification Seq# of the file for that.

  16. Josh says:

    @alegr1: Was that facetious or did you miss IconCache.db? %USERPROFILE%AppDataLocalIconCache.db (on Vista+) and %USERPROFILE%Local SettingsApplication DataIconCache.db (on 2003 and earlier) do exactly that for standard icons. For more complex stuff (like video/image thumbnails), there is a per-folder thumbs.db created if and when it is viewed in Thumbnail mode.

  17. Danny says:


    The same way antiviruses avoid zip bombs when they are set to "scan files in archives" so does explorer can. It's not a big deal to avoid them.

  18. alegr1 says:


    These caches don't seem to work, because the thumbnails are rebuilt every time. And it looks so ugly, when you log in, and all the icons on the desktop are cleared, and then rebuilt. It looks like very amateurish programmer wrote that.

    It's possible, also, that the caches are using wrong timestamps instead on unadulterated NTFS timestamps.

  19. Magnum says:

    One of the things I always do when installing a new system is regsrv32 /u zipfldr.dll.  I hate it how Explorer opens zip files, especially when I use it to search my system for a file.

Comments are closed.

Skip to main content