Upload failed: Server FIle Updated. We're sorry, someone updated the server copy and it's note possible to upload your changes now

I get the dreaded "upload failed We're sorry, someone updated the server copy"... bug every few weeks, usually with word documents. I get (and can easily reproduce) the problem in both onedrive personal and onedrive for business.

Like you, I am the one and only user of my onedrive, and I only have it installed on one computer. The problem is if you do two things quickly (such as create a new word doc, the quickly edit the name, or open it too quickly), you get this error. Basically, onedrive has a fundamental design flaw in that if you do two things to a file one after the other, it fails.

Its easy to reproduce.  The only work around is to pause for about 20 seconds between doing any activity on the same file. E.t. create the file, wait.  open the file, wait. Edit the file, save file, wait.  Then rename the file then wait etc. Then you dont get the error.

There are lots of other problems like this. E.g. if you create a new folder in a onedrive directory in file explorer, as you type the name in, it randomly truncates your name and starts uploading it before you have finished typing. I have learned the hard way you have to first create the folder, wait for 30 seconds, then edit the name of the folder, then wait, then you can put files in it.

I have never had this issue with dropbox or google drive. MS have some pretty poor coding when 3rd parties write better tools then MS can.

Why is that to be expected?? Isn't the main feature of any sync technology the automatic updating of files according to the most recent time stamp? People sync all sorts of things in more than one location, myself included, and this is ONLY a problem with onedrive and Office files. It happens with all of the main Office programs, not just Excel, and it does not happen when syncing to another cloud storage service. It seems to only happen when it tries to sync while you have the file open, but it seems to be trying to sync constantly, so the problem happens constantly. It is not a non-Microsoft application issue. Either make it stop syncing files that are currently open, or fix whatever communication problem these two Microsoft services are having. It's extremely annoying

I found an option in Excel that may prevent the problem also in SkyDrive/SharePoint, etc.

In Excel 2013 or above, go to File > Options > Trust Center > Trust Center Settings > Protected View. I believe the problem does not occur if you disable protected view for "files originating from the Internet":

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