Why don’t I get thumbnails for files that are marked offline?


A customer deployed a data archival system that migrates files to network-attached storage after a period of inactivity. The customer reported that when a file is archived, they are no longer able to see thumbnails in Explorer. The customer contacted the vendor of the archival system, and the vendor explained that the archival system's default configuration sets the FILE_ATTRIBUTE_OFFLINE attribute when a file is archived. And Explorer doesn't show thumbnails for offline files.

The customer wanted to know whether this was by design.

Yes, this is by design. Explorer assumes that files that are marked offline must not be accessed casually, because any attempt to access an offline file will cause it to be recalled from archival storage and brought online. And you can't generate a thumbnail for a file without accessing the file.

If Explorer were to read a file in order to generate a thumbnail, that would mean that opening a folder would recall every file!

The customer is faced with a choice,

If you set the offline attribute when a file is archived, then Explorer will not recall the file until you take an explicit action on the file, like double-clicking it. This means that Explorer will not read the file in order to generate a thumbnail or a customized icon or a preview, nor will it read the file in order to extract other properties. (And it expects all shell extensions to respect the offline attribute and follow the same policy.) This is good for your archival system because it means that archived files stay archived until somebody actually wants it, but it means that you lose out on some features because those features would trigger a recall.

On the other hand, if you do not set the offline attribute when a file is archived, then Explorer will access the file in order to generate thumbnails and customized icons and previews, and it will read the file in order to extract other properties. This gives you all the features of normal files, but it has a good chance of negating the work your archival system performed because it will trigger a file recall.

On the other hand, if the archival storage system offers fast retrieval of file contents (possibly with a policy of not actually recalling the file until some other signals are received), then maybe omitting the offline attribute is the right thing.

You'll want to try it both ways and see which you like better. But at least you now understand the tradeoffs.

Comments (12)
  1. Karellen says:

    Previously: https://blogs.msdn.microsoft.com/oldnewthing/20051128-10/?p=33193/

    (I’m sure you’ve covered this a couple of other times in the past, too, but my search-fu is weak today)

  2. Yukkuri says:

    I am not sure why anyone in a position to ask this question needs to ask it…

  3. Joshua says:

    I wonder if this would be a good time to publish the spec for thumbs.db so the archiver can populate it.

  4. James Sutherland says:

    Actually opening (hence retrieving) the file to *generate* a thumbnail would be a bad thing, certainly (which is pretty much the whole point of the FILE_ATTRIBUTE_OFFLINE attribute, after all) – but what about using a cached thumbail previously generated? Does Explorer ignore or expire those when it sees a file has been migrated, or does setting FILE_ATTRIBUTE_OFFLINE invalidate the cached thumbnail for some reason?

    1. morlamweb says:

      I’d bet that Explorer doesn’t use the thumbnail cache for offline files because the guiding principle of “offline” is “don’t touch the file except for an explicit request from the user”. Imagine if it did check the thumbs.db for a thumbnail for an offline file, found nothing, and then decided to generate one? Simply not loading any thumbnails for offline files is the safest thing to do.

  5. Augusto Ruiz says:

    So… no caching is done using the Thumbs database? This is one good use case for that… if the file is offline but you have a thumb in thumbs.db, use it (and maybe overlay an icon showing the offline status)…

  6. GWO says:

    It can’t help that since those flags were named the meaning of those terms have reversed in some contexts. Now, if someone says that certain files are offline and others are online, I would expect the former to be on some local fast media, and the latter to require fetching from some kind of intranet/internet/cloud service.

    1. pc says:

      Long ago, software help files were often labeled “on-line help”, and I found it odd, because it was clearly off-line as one didn’t need to dial up to the internet to get it. They were obviously trying to contrast it with printed manuals (which I suppose are another type of “off-line”), but it is interesting how fast people’s expectations can change, and how terminology sometimes takes a while to catch up and can even reverse meanings like that.

      1. GWO says:

        And these days on-line help is probably online again. Of course, I’m old enough to remember when “wireless” was an slightly outmoded term for a valve / transistor radio receiver.

        1. pc says:

          You mentioning how “wireless” has changed meanings somehow reminded me of this, though I’m not sure why. Maybe how “Wi-fi” means “internet access” now instead of a new-fangled way of wirelessly accessing a network:
          https://www.reddit.com/r/techsupportgore/comments/46i93i/my_friend_at_uni_found_a_wifi_cable/

  7. DWalker07 says:

    This is exactly why “hide extensions for known filetypes” is wrong to be set as default. Two files named … for example… “readme”, where one is an exe and one is a txt file, can’t be distinguished if the icon is supposed to be the distinguishing element, and if the icons aren’t shown when the files are offline.

    1. Alex Cohn says:

      Some while ago, the icons were fetched from a local DLL based exclusively on the .three-letter well-known extension. I cannot think of an excuse not to apply this policy to _OFFLINE files

Comments are closed.

Skip to main content