File Modified date misalignment in SharePoint, Explorer View and file shares/drives

Most of you have been using for ages now the Explorer View of a Document Library. It’s indeed one of the most controversial features SharePoint (sometimes painful for IT Pros) offered since early days but is arguably one of those feature that seduced the “normal” and non-IT users thanks to the easiness of move/copy drag and drop.

During a recent scenario we discovered a misalignment between a file’s “Modified” SharePoint metadata field and the actual “Date Modified” of the file as displayed in the Explorer View (if one uses the Explorer View of a Document Library or if the Document Library is mapped as a network drive on the users computer – very common scenario for users) or if one checks the date of the file properties in Office applications (e,g Word, Excel, etc)

The complete scenario is as follows: the “Modified” column in SharePoint has been basically overwritten during a copy/move operation performed using the Document Library Explorer View and now reflects the “Modified” date in which the moving operation was done instead of the last modification date of the file itself.

Below the picture displays the Modified date as it appears in SharePoint (2/08/2012) which is indeed the date where the file was moved from the source to this Document Library:

Below the picture displays the Modified date as it appears if we use the Explorer View on the same Document Library (with the original date when the file was truly modified (27/7/2012):

When you upload a document to a document library SharePoint will use the last modified date as the date which the upload was done while the Explorer view (Windows) will display the modified date stored as property of the file itself!

This behavior can also be explained from another angle: “Modified” date in SharePoint is actually the Content Type modification date while “Modified” date in Windows (classical file shares or drives) is the date of the file itself.

Well, in our case this behavior creates big problems given the fact that many users continue to use the Explorer View in order to access and find their work files in their department or team site (most of them simply remember that the file they look for it was modified at a certain date in time so they will look for that file rather sorting on the modified date than on performing a search).

We looked than for a way of mapping these inner file properties reported above, carrying the last modification date of the file, onto a site column to be shown in a Document Library View. We know that this approach is very useful for search purposes: in Shared Services Administration -> Search Administration -> Metadata Property Mapping we can map the properties Basic:14(Date and Time), Basic:16(Date and Time), ows_Modified(Date and Time) onto a new property labelled, for instance, LastModifiedTime (see pic below).

Nevertheless, this mapping seems to be useful for search purposes only and unfortunately Microsoft confirmed that there is no out-of-the-box configuration for our purpose.

It seems that the only out-of-the-box solution would be to use Backup and Restore which will then preserve the original last modified dates…or custom development of course (event handlers, etc)