none
[MS-STWEB] Server returns empty SyncToken when file is renamed RRS feed

  • Question

  • Hi, guys,

    I am developing mobile app that synchronizes SkyDrive folder specified by user with the local folder on their device. I use [MS-STWEB] for implementing synchronization but I am stuck in a trouble.

    I have folder with files on my SkyDrive.

    1. When I start syncing my SkyDrive folder with the folder on my device I send GetChangesSinceTokenRequest with empty SyncToken (as described here). So I get the list of folders and files that are children of my folder and new SyncToken. It's OK, I remember that SyncToken.

    2. When I delete or add files in my SkyDrive folder and send new GetChangesSinceTokenRequest with the received last time SyncToken I get only changes and new SyncToken. And it's OK, again.

    3. But if I simply rename one of files are in my SkyDrive folder and send new GetChangesSinceTokenRequest with the last received SyncToken I get empty list of changes and empty SyncToken in response (as if I send in the request invalid SyncToken, as described here).

    So there is a question: why it happens? I expect that in that case I'll get list contains at least two entries: the file with previous name is deleted and the new one (with new name) is added to folder.

    Best regards, Yuriy Muzyukin.



    Wednesday, July 25, 2012 1:36 PM

Answers

  • Hi Yuriy,

    Thank you for the detailed description, now it is clear what you are trying to do. By the way, is any reason that in your xml snippets you are using not consistent cases?

    The [MS-STWEB] doesn’t cover renaming a file or folder. I’ve submitted suggestion to cover these cases, too.

    The key elements are in your last xml snippet, <multistatus> and <SyncToken> are empty. The SyncToken is empty indicates that the sent synchronization token was not valid. We know in your case this is because one file was renamed. When you have a not valid token, you have to reissue the request with an empty SyncToken.

    Thanks, Vilmos

    Monday, October 1, 2012 4:05 PM

All replies

  • Hi Yuriy:

    I have alerted the open specifications team regarding your inquiry. A member of the team will be in touch soon.


    Regards, Obaid Farooqi

    Wednesday, July 25, 2012 6:45 PM
    Owner
  • Hi Yuriy,

    I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon.

    Regards,
    Vilmos Foltenyi - MSFT


    • Edited by Vilmos Foltenyi Tuesday, September 4, 2012 10:25 PM corrected the name
    Thursday, July 26, 2012 5:08 PM
  • Hi Yuriy,

    Thank you for your patience. I‘m still researching your question, I asked other groups, too. Soon I’ll provide you with the finding.

    Thanks, Vilmos


    • Edited by Vilmos Foltenyi Tuesday, September 4, 2012 10:26 PM corrected the name
    Saturday, September 1, 2012 1:02 AM
  • Hi Yuriy,

    How did you rename the file? If you use, e.g., Windows Explorer the three dates associated with the file, created, modified, and accessed are remained unchanged. Perhaps this is the reason that the rename was undetected by the GetChangesSinceTokenRequest.

    Thanks, Vilmos

    Thursday, September 6, 2012 12:51 AM
  • Hi Yuriy,

    Because there is no respond to this issue since my last posting, I assume your problem is solved and I’ll mark this thread as answered.

    Thanks, Vilmos

    Wednesday, September 12, 2012 7:09 PM
  • Hi Vilmos,

    Sorry for my delayed answer but I have changed my career and now I don't work with the project where I used [MS-STWEB]. So I haven't watched this thread periodically.

    For the answer to your question: I rename file using the function "Rename" on Web-service of SkyDrive (using Chrome web-browser).

    And 'GetChangesSinceTokenRequest' has not only undetected this change but responses with empty changes-list and with empty SyncToken (even if there are other changes in the folder for which I requested changes-list).

    P.S. Moreover: when we rename file in the remote SkyDrive folder (using Web-service) it get new WebDAV URL. I think it is obviously that 'GetChangesSinceTokenRequest' should respond (at least) that new file is added.

    Thanks!

    Best regards, Yuriy Muzyukin.

    Thursday, September 13, 2012 3:11 PM
  • Hi Yuriy,

    The documentation, [MS-STWEB] v20120630 “3.1.4.1 GetChangesSinceToken” says
    If the synchronization token in the request is not considered valid by the server (such as the synchronization token being too old), the server MUST return an empty set and empty synchronization token

    Let’s assume that it isn’t the case, but please check it.

    Please give detailed information about your server side including versions.

    Thanks, Vilmos

    Friday, September 14, 2012 9:56 PM
  • Hi Vilmos,

    Here is detailed explanation:

    1. Assume I have folder 'Documents' in my root SkyDrive folder. In 'Documents' folder I have file 'Document1.docx':

    2. I have mobile device with an app that synchronizes my data in SkyDrive and in my local mobile device's storage. This app uses [MS-STWEB] to do so. I set this app to synchronize my 'Documents' folder. App does it as follows:

    For the first time it sends HTTP-request:

    POST https://docs.live.net/SkyDocsService.svc HTTP/1.1

    SOAPAction: GetChangesSinceToken
    User-Agent: Microsoft Office OneNote 2010
    Authorization: <my private token>
    Content-Type: text/xml; charset=utf-8

    <?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <GetChangesSinceTokenRequest xmlns="http://schemas.microsoft.com/clouddocuments">
            <BaseRequest xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                <ClientAppId>Microsoft Office/14.0 (Windows NT 6.1; Microsoft OneNote 14.0.6112; Pro)</ClientAppId>
                <Market>en-US</Market>
                <SkyDocsServiceVersion>v1.0</SkyDocsServiceVersion>
            </BaseRequest>
            <DavUrl>https://docs.live.net/9824CD55980BDBB7/Documents</DavUrl>
            <SyncToken></SyncToken>
        </GetChangesSinceTokenRequest>
    </s:Body>
    </s:Envelope>

    As you can see it follows documentation instructions: "The client MUST first issue a request with an empty synchronization token; and the server returns the set of all files and folders contained by the specified folder, plus a synchronization token for the set." (See here)

    OK, the request is responded by your server with the body:

    <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:body>
      <getchangessincetokenresponse xmlns="http://schemas.microsoft.com/clouddocuments">
       <minamialonesyncinterval>30</minamialonesyncinterval>
       <minbackgroundsyncinterval>600</minbackgroundsyncinterval>
       <minrealtimesyncinterval>5</minrealtimesyncinterval>
       <syncdata>
        <multistatus xmlns="DAV:">
         <response>
          <href>https://d.docs.live.net/9824cd55980bdbb7/Documents</href>
          <propstat>
           <prop>
            <displayname>Documents</displayname>
            <lockdiscovery>
             <supportedlock>
              <isfolder>t</isfolder>
              <iscollection>1</iscollection>
              <ishidden>0</ishidden>
              <isreadonly>0</isreadonly>
              <getcontenttype>application/octet-stream</getcontenttype>
              <getcontentlength>0</getcontentlength>
              <creationdate>2012-05-21T06:42:56Z</creationdate>
              <getlastmodified>Sat, 15 Sep 2012 08:43:30 GMT</getlastmodified>
              <win32lastmodifiedtime xmlns="urn:schemas-microsoft-com:">Sat, 15 Sep 2012 08:43:30 GMT</win32lastmodifiedtime>
              <win32creationtime xmlns="urn:schemas-microsoft-com:">Mon, 21 May 2012 06:42:56 GMT</win32creationtime>
              <win32lastaccesstime xmlns="urn:schemas-microsoft-com:">Sat, 15 Sep 2012 08:43:30 GMT</win32lastaccesstime>
              <resourcetype>
               <collection></collection>
              </resourcetype>
              <authoritative-directory xmlns="http://schemas.microsoft.com/repl/">t</authoritative-directory>
              <resourceid xmlns="http://schemas.microsoft.com/clouddocuments">9824CD55980BDBB7!134</resourceid>
              <progid xmlns="http://schemas.microsoft.com/clouddocuments"></progid>
             </supportedlock>
            </lockdiscovery>
           </prop>
           <status>HTTP/1.1 200 OK</status>
          </propstat>
         </response>
         <response>
          <href>https://d.docs.live.net/9824cd55980bdbb7/Documents/Document1.docx</href>
          <propstat>
           <prop>
            <displayname>Document1.docx</displayname>
            <lockdiscovery>
             <supportedlock>
              <lockentry>
               <lockscope>
                <exclusive></exclusive>
               </lockscope>
               <locktype>
                <write></write>
               </locktype>
              </lockentry>
             </supportedlock>
             <isfolder>f</isfolder>
             <iscollection>0</iscollection>
             <ishidden>0</ishidden>
             <isreadonly>0</isreadonly>
             <getcontenttype>application/vnd.ms-word.document.12</getcontenttype>
             <getcontentlength>17325</getcontentlength>
             <creationdate>2012-09-15T06:44:17Z</creationdate>
             <getlastmodified>Sat, 15 Sep 2012 08:43:30 GMT</getlastmodified>
             <win32lastmodifiedtime xmlns="urn:schemas-microsoft-com:">Sat, 15 Sep 2012 08:43:30 GMT</win32lastmodifiedtime>
             <win32creationtime xmlns="urn:schemas-microsoft-com:">Sat, 15 Sep 2012 06:44:17 GMT</win32creationtime>
             <win32lastaccesstime xmlns="urn:schemas-microsoft-com:">Sat, 15 Sep 2012 08:43:30 GMT</win32lastaccesstime>
             <resourcetype>
              <resourceid xmlns="http://schemas.microsoft.com/clouddocuments">9824CD55980BDBB7!141</resourceid>
             </resourcetype>
            </lockdiscovery>
           </prop>
           <status>HTTP/1.1 200 OK</status>
          </propstat>
         </response>
        </multistatus>
       </syncdata>
       <synctoken>LM=63483295410447;ID=9824CD55980BDBB7!134;LR=63483295762540;EP=0</synctoken>
      </getchangessincetokenresponse>
     </s:body>
    </s:envelope>

    OK, it's right. Remember that it returns SyncToken: LM=63483295410447;ID=9824CD55980BDBB7!134;LR=63483295762540;EP=0.

    3. Me or somebody (I shared 'Document1.docx' with) renames the file as follows:

    rename

    4. I want to synchronize this change with the local storage in my mobile device. My app sends HTTP-request:

    POST https://docs.live.net/SkyDocsService.svc HTTP/1.1

    SOAPAction: GetChangesSinceToken
    User-Agent: Microsoft Office OneNote 2010
    Authorization: <my private token>
    Content-Type: text/xml; charset=utf-8

    <?xml version="1.0" encoding="utf-8"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <GetChangesSinceTokenRequest xmlns="http://schemas.microsoft.com/clouddocuments">
            <BaseRequest xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                <ClientAppId>Microsoft Office/14.0 (Windows NT 6.1; Microsoft OneNote 14.0.6112; Pro)</ClientAppId>
                <Market>en-US</Market>
                <SkyDocsServiceVersion>v1.0</SkyDocsServiceVersion>
            </BaseRequest>
            <DavUrl>https://docs.live.net/9824CD55980BDBB7/Documents</DavUrl>
            <SyncToken>LM=63483295410447;ID=9824CD55980BDBB7!134;LR=63483295762540;EP=0</SyncToken>
        </GetChangesSinceTokenRequest>
    </s:Body>
    </s:Envelope>

    Note that it sends the SyncToken it received last time. But the response is:

    <s:envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:body>
      <getchangessincetokenresponse xmlns="http://schemas.microsoft.com/clouddocuments">
       <minamialonesyncinterval>30</minamialonesyncinterval>
       <minbackgroundsyncinterval>600</minbackgroundsyncinterval>
       <minrealtimesyncinterval>5</minrealtimesyncinterval>
       <syncdata>
        <multistatus xmlns="DAV:"></multistatus>
       </syncdata>
       <synctoken></synctoken>
      </getchangessincetokenresponse>
     </s:body>
    </s:envelope>

    As you can see: it returns no SyncToken.
    And YES! I'm sure the SyncToken LM=63483295410447;ID=9824CD55980BDBB7!134;LR=63483295762540;EP=0 was valid when my app was sending it in the second HTTP-request.

    Hope it helps.

    Best regards, Yuriy Muzyukin.




    Saturday, September 15, 2012 9:45 AM
  • Hi Yuriy,

    Thank you for the detailed description, now it is clear what you are trying to do. By the way, is any reason that in your xml snippets you are using not consistent cases?

    The [MS-STWEB] doesn’t cover renaming a file or folder. I’ve submitted suggestion to cover these cases, too.

    The key elements are in your last xml snippet, <multistatus> and <SyncToken> are empty. The SyncToken is empty indicates that the sent synchronization token was not valid. We know in your case this is because one file was renamed. When you have a not valid token, you have to reissue the request with an empty SyncToken.

    Thanks, Vilmos

    Monday, October 1, 2012 4:05 PM
  • ... By the way, is any reason that in your xml snippets you are using not consistent cases?...

    What is wrong with my xml snippets?

    P.S. Reissuing the request with an empty SyncToken is what I actually do in that case... But it is quite badly:

    1. It can significantly increase amount of received data (it's especially crucial for mobile app that uses slow internet connection and has limited battery life);

    2. To avoid increase amount of received data I should write code for my app that remembers, for example, date and time of last modification of each file and checks it with the last modification time on the server (for each file). And what is the profit from using the 'GetChangesSinceToken' then?

    3. The file with old name will be not in the list of newly received <multistatus>. So I should write extra code for my app that checks if there are files in the local folder that are not in the list, and if so - should app delete them or upload them to server? What if I added these files to my local folder and expect them to be uploaded to server and then to be synced with other devices (for example, my desktop using SkyDrive app)? More meta data to store state of my files? More error-prone code in my project?

    By the way, thank you, Vilmos, for your help. Hope this issue would be fixed some day.

    Best regards, Yuriy Muzyukin


    Monday, October 1, 2012 6:03 PM
  • Hi Yuriy,

    I just wondered is any reason that in one place you are using <GetChangesSinceTokenRequest> as it is documented and a few lines below <getchangessincetokenresponse> different case usage as it documented; the snippets are understandable.

    How efficient the SkyDrive protocol is and how it could be made more efficient is not the subject of this forum. Try
    http://social.msdn.microsoft.com/Forums/en-US/messengerconnect/threads
    http://skydriveapiclient.codeplex.com/

    Thanks, Vilmos

    Wednesday, October 3, 2012 12:40 AM
  • I just wondered is any reason that in one place you are using <GetChangesSinceTokenRequest> as it is documented and a few lines below <getchangessincetokenresponse> different case usage as it documented; the snippets are understandable.

    Hi Vilmos,

    The case is different from the documented only in responses from Microsoft's servers. I use case-sensitive XML in all requests I send. But the responses are all in lower case. However the content in responded XMLs is case-sensitive: "<displayname>Document1.docx</displayname>".

    Maybe the problem is with the service I used to check the protocol behavior (http://hackst.com/), but maybe that is another issue with implementation of MS-STWEB by Microsoft (but I can live with it however). I didn't research in it.

    Best regards, Yuriy Muzyukin

    Wednesday, October 17, 2012 2:26 PM
  • Hi Yuriy,

    Thank you for your explanation about the case usage in your snippets. If you need additional assistance, please let us know after you do more research.

    Thanks, Vilmos

    Monday, December 10, 2012 4:50 PM