Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Custom Provider for FileSync Provider RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hello im in devolping a custom Provider for the FileSync Provider "SaveItemChange" over the IFileDataRetriever works perfectly since the CTP2. :)

    But i have a problem with change detection i my provider!
    If i found a new file, i try to Create it in my SqlMetadataStore:


     item = metadata.CreateItemMetadata(new SyncId(????"new byte[24]"????, false), newVersion);

    For the FileSyncProvider the SyncID must be a 24 length byte array. What is that how you build this unique id in your FileSyncProvider? Its to long for a simple Guid.

    I also dont know how to implement the LoadChangeData methode. Must i return a IFileDataRetriever object like the on i get from the FileSycnProvider?
    Its really hard to build a compatible provider without the source of the other one. :(

    Is there a chance to look in the source as MS Partner for interoperability?

    Please help.
    • Moved by Max Wang_1983 Thursday, April 21, 2011 1:28 AM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Monday, June 15, 2009 3:27 PM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote
    Hi Steffen,

    For your item ids you should be using the SyncGlobalId class.  And you are correct, you must return a IFileDataRetriever (that you implement) from LoadChangeData.

    If you do not want to use AbsoluteSourceFilePath you should return a NotImplementedException from that method and the FSP will then use your Stream instead.

    Hope this helps.

    -Jesse
    Tuesday, June 16, 2009 4:57 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    There is a other great issue i found in the FileSyncProvider!

    If i make a (for example DB provider) to work with the FileSysncProvider, in the "LoadChangedData" methode i return an object for type "IFileDataRetriever".

    I give a System.IO.Stream in this object, but why the FileSyncProvider try to copy the file with the absolut path string????

    Because if the "AbsoluteSourceFilePath" is \\test\\test.jpg (is a path on a mobile device for example) i get an:

    Exception = {"System can not found the file. (Exception from HRESULT: 0x80070002)":null}


    That makes it really unflexible, the sync contend can only come from local file system. :(

    It because i have make a provider that access streams on a mobile device. Its a real System.IO.Stream but the path to a file is for example \\test\\test.jpg
    and that the FileSyncProvider doesnt understand. 

    So why if there is a  opportunity for a Stream if you dont use it??? Attributes and the other file stuff is already in the "FileData" object in the given "IFileDataRetriever"

    Tuesday, June 16, 2009 8:12 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    If you help me i can give you a CEFileSyncProvider!
    It works via RAPI2 and can sync Files betwen PC <> PPC
    :)
    Tuesday, June 16, 2009 8:15 AM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Hi Steffen,

    For your item ids you should be using the SyncGlobalId class.  And you are correct, you must return a IFileDataRetriever (that you implement) from LoadChangeData.

    If you do not want to use AbsoluteSourceFilePath you should return a NotImplementedException from that method and the FSP will then use your Stream instead.

    Hope this helps.

    -Jesse
    Tuesday, June 16, 2009 4:57 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Great, all works fine now! Thanks!!!

    One last question for what is the "TempDirectoryPath" Property in the FileSyncProvider? What for temp Files will be created?
    Friday, June 19, 2009 8:52 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi -

    When we download files - we download files to a temporary location first before moving it to the actual location.

    Thanks
    Deepa
    Deepa ( Microsoft Sync Framework)
    Friday, June 19, 2009 10:54 PM
    Answerer