A customer observed that sometimes, the last-modified timestamp on a file would change even though nobody modified the file, or at least consciously took any steps to modify the file. In particular, they found that simply double-clicking the file in Explorer was enough to trigger the file modification.
It took a while to puzzle out, but here's what's going on:
When you double-click a file in Explorer, Explorer adds it to the Recent Items list. Internally, this is done by creating a shortcut to the item. The nice thing about a shortcut is that it knows how to track its target. That way, if you move an item, then try to open it from the Recent Items list, the shortcut tracking code will try to find where you moved it to. You moved the file. The shortcut still works. Magic.
Shortcut target tracking magic is accomplished with the assistance of object identifiers, and object identifiers, as we saw earlier, are created on demand the moment somebody first asks for one.
And that's where the file modification is coming from. If the file is freshly-created, it won't have an object identifier. When you create a shortcut to it (which happens implicitly when it is added to the Recent Items list), that triggers the creation of an object identifier, which in turn updates the last-modified time on the file.
Frustratingly, the LinkResolveIgnoreLinkInfo and
NoResolveTrack policies do not prevent the creation of object
identifiers.
Those policies control whether the tracking information is used
during the resolve process,
but they don't control whether the tracking information is
obtained during shortcut creation.
(Who knows, maybe you're creating the shortcut to be used on a machine
where those policies are not in effect.)
To suppress collecting the volume information and object identifier
at shortcut creation time,
you need to pass the
SLDF_ and
SLDF_ flags
to the
IShellLinkDataList::
method when you create the shortcut.