I'm new in SharePoint - please let me know if there is a better place to submit a bug report on SharePoint Server side WebDav beahviour. Involves XML and is purely (I think!) server side and I'm not sure where is the best place for this.
We use SharePoint to store files (in a SharePoint library) and we access them using Microsoft SharePointOnline (Web) and also using WebDav.
We have a problem that affects our workflow: if we change the name of a folder using Microsoft SharePoint Web (and probably Microsoft Graph API): the modification times reported by the WebDav API is updated to the time that the folder name changed!
For example:
HTTP REQUEST (edited for Cookies, etc.):
PROPFIND /sites/l/S/test22/ HTTP/1.1
Host: swisspolar.sharepoint.com
Referer: https://swisspolar.sharepoint.com/sites/l/S/
Accept-Encoding: gzip
HTTP RESPONSE:
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:" xmlns:Office="urn:schemas-microsoft-com:office:office"
xmlns:Repl="http://schemas.microsoft.com/repl/">
<D:response>
<D:href>https://swisspolar.sharepoint.com/sites/l/S/test22/</D:href>
<D:propstat>
<D:prop>
<D:displayname>test22</D:displayname>
<D:lockdiscovery/>
<D:supportedlock/>
<D:isFolder>t</D:isFolder>
<D:iscollection>1</D:iscollection>
<D:ishidden>0</D:ishidden>
<D:getcontenttype>application/octet-stream</D:getcontenttype>
<D:getcontentlength>0</D:getcontentlength>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
<Repl:authoritative-directory>t</Repl:authoritative-directory>
<D:getlastmodified>Thu, 01 Apr 2021 23:15:06 GMT</D:getlastmodified>
<D:creationdate>2021-03-30T19:00:24Z</D:creationdate>
<Repl:repl-uid>rid:{6F3AB737-05C6-47C0-BABA-08110E241BDA}</Repl:repl-uid>
<Repl:resourcetag>rt:6F3AB737-05C6-47C0-BABA-08110E241BDA@00000000005</Repl:resourcetag>
<D:getetag>"{6F3AB737-05C6-47C0-BABA-08110E241BDA},5"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>https://swisspolar.sharepoint.com/sites/l/S/test22/test.docx</D:href>
<D:propstat>
<D:prop>
<D:displayname>test.docx</D:displayname>
<D:lockdiscovery/>
<D:supportedlock>
<D:lockentry>
<D:lockscope>
<D:exclusive/>
</D:lockscope>
<D:locktype>
<D:write/>
</D:locktype>
</D:lockentry>
</D:supportedlock>
<D:getlastmodified>Thu, 01 Apr 2021 23:15:06 GMT</D:getlastmodified>
<D:creationdate>2021-04-01T23:10:45Z</D:creationdate>
<D:getcontentlength>17641</D:getcontentlength>
<Repl:repl-uid>rid:{85A1E1F5-770D-4F72-8E7D-4AC87C0E62E3}</Repl:repl-uid>
<Repl:resourcetag>rt:85A1E1F5-770D-4F72-8E7D-4AC87C0E62E3@00000000006</Repl:resourcetag>
<D:getetag>"{85A1E1F5-770D-4F72-8E7D-4AC87C0E62E3},6"</D:getetag>
<Office:modifiedby>i:0#.f|membership|carles.pinaestany@swisspolar.ch</Office:modifiedby>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
If I pay attention at D:getlastmodified of the returned elements:
-test22 folder: Thu, 01 Apr 2021 23:15:06 GMT
-test22/test.docx: Thu, 01 Apr 2021 23:15:06 GMT
Via SharePoint Web I change the name of the folder from test22 to test23 and I do the same request (PROPFIND /test23) and I get these times:
-test23 folder: <D:getlastmodified>Fri, 02 Apr 2021 13:40:13 GMT</D:getlastmodified>
-test23/test.docx: <D:getlastmodified>Fri, 02 Apr 2021 13:40:13 GMT</D:getlastmodified>
If I check the last modified time of the file using SharePoint Web or Microsoft Graph API: the get last modified of the file is the previous one. WebDav getlastmodified for the files is broken on changing the name of the folder.
We are using certain software that connects to SharePoint via WebDav and this is causing problems.
I've checked other WebDav implementations (Apache) and renaming a folder or changing the modified time of a folder doesn't affect the modified time of the files. SharePoint Microsoft Graph API does not do this either so to me seems like a WebDav server side bug.
Can this be fixed? I'm happy to verify or provide more information, just let me know what you need if you cannot reproduce this problem or need further explanation. Feel free to contact me in personal message if needed as well.
Thank you very much,
Carles
