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 Modifiedof 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)


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

  1. Marty L says:

    Thanks for the concise description of the problem. This has been a very annoying issue with our sharepoint users. Another example of the poor design & implementation of sharepoint.

    • uscatu says:

      Same for us 🙂 We actually developped a feature. Applied on the site collection/site/library, it creates a new column (file modified) filled in with the file respective modified date. the Create or Update event handler on the respective library calls the method to update this metadata.

  2. Nik says:

    Hi Uscatu,

    Are you able to share that feature. I also want to confirm is this related to SSL site with https or it doesnt mater which protocol has been used.
    is the site having issue is using https?

    • uscatu says:

      Hi Nik,

      It’s independent of SSL. we only have http from inside (Intranet).
      I’ll check with my team at the end of the week if I can share the code with you. (I’m not in office currently).

      • Nik says:

        Hi Uscatu,

        Thanks for the Reply. Appreciate your time to reply back.

        Just to confirm from you does Backup restore works for you. if yes? Which type of backup restore process you have used?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: