A family of Microsoft spreadsheet software with tools for analyzing, charting, and communicating data.
I believe this is a bug in the WebDAV client implementation of the Excel Desktop app. If you implement your own WebDAV server (like we do), there is a simple solution to the problem.
I used fiddler to analyze the WebDAV traffic between Excel and the WebDAV server.
As follows:
=== Excel startup (edit mode allowed) ===
OPTIONS, HEAD, OPTIONS, OPTIONS, LOCK, GET, PROPFIND, HEAD
=== Saving ===
LOCK, PUT
The problem appears to be in the way that the PROPFIND response is processed. Excel (like Word) asks for these properties:
<D:creationdate/><D:getlastmodified/><Office:modifiedby/>
Our WebDAV server returns the creation date and last modified date in UTC, both certainly in the past. However, Excel somehow concludes incorrectly that the last modified date is newer than the client copy of the workbook.
The fix (actually a workaround): do not tell Excel what the last modified date of the document is. In our patched WebDAV server, this is the response for Excel:
<?xml version="1.0" encoding="Windows-1252"?>
<D:multistatus xmlns:Office="urn:schemas-microsoft-com:office:office" xmlns:D="DAV:">
<D:response>
...
<D:propstat>
<D:status>HTTP/1.1 200 OK</D:status>
<D:prop>
<D:creationdate>2016-08-26T12:56:51Z</D:creationdate>
<Office:modifiedby>Berend Engelbrecht</Office:modifiedby>
</D:prop>
</D:propstat>
</D:response>
</D:multistatus>
As you can see, we simply leave out <D:getlastmodified/> in the response. Code in the handler of the PROPFIND request:
case "getlastmodified":
{
if (!IsExcel)
this.WriteModified(item);
continue;
}
Where IsExcel is implemented with:
return (Context.Request.UserAgent.IndexOf("Microsoft Office Excel", StringComparison.InvariantCultureIgnoreCase) >= 0);