Overcome Error “The metadata store replica is already in use” while doing a File Sync

Published Jan 15 2019 12:51 PM 133 Views
First published on MSDN on Mar 30, 2010

While doing a file Sync we may see error that the metadata store replica is already in use.

This happens after the first file Sync operation succeeds , subsequent attempts for file Sync operations results in the above error.

Code snippet :

Guid sourceID;

Guid destID;

FileSyncProvider sourceReplica;

FileSyncProvider destReplica;

SyncOrchestrator so;

sourceID = getSyncID(@"C:\Sync\Source\File.ID").GetGuidId();

destID = getSyncID(@"C:\Sync\Destination\File.ID").GetGuidId();

sourceReplica = new FileSyncProvider(sourceID, @"C:\Sync\Source\");

destReplica = new FileSyncProvider(destID, @"C:\Sync\Destination\");

so = new SyncOrchestrator();

so.LocalProvider = sourceReplica;

so.RemoteProvider = destReplica;

so.Direction = SyncDirectionOrder.Download; // UploadAndDownload;


lblStatus.Text = "Sync Completed";


private SyncId getSyncID(string SyncFilePath)


SyncId replicaID = null;

Guid guid__1;

if (!File.Exists(SyncFilePath))


guid__1 = Guid.NewGuid();

replicaID = new SyncId(guid__1);

FileStream fs = File.Open(SyncFilePath, FileMode.Create);

StreamWriter sw = new StreamWriter(fs);







String guidString;

FileStream fs = new FileStream(SyncFilePath, FileMode.Open);

StreamReader sr = new StreamReader(fs);

guidString = sr.ReadLine();

guid__1 = new Guid(guidString);

replicaID = new SyncId(guid__1);




return replicaID;



Reason we are seeing the above error while doing a file sync

We put the replica id file into the same folder as source/destination – so we were sync’ing the file.id file as well and ending up with the same file.id for both. So when we tried to initialize the filesyncprovider with the same replica id ( a global mutex will disallow this).

Solutions -

1) Do not keep the Replica ID file in the same location as the files to be Synched.

2) If you need to put the file.id file under the same root folder – specifically add it to your exclude filter to * not *sync.

3) There are constructors on the FSP that do not take a replica id. It essentially translates into a zero guid in the native layer that then creates a guid for you and sticks it into the metadata store. You use the same constructor on all subsequent sync’s as well and we just use the replica id that we find in the file. This solution is recommended unless there is a reason you  need this replica id value at the app level ( note – you still could get it by accessing a property on the FileSyncProvider) or you plan on reusing the metadata store for multiple replicas.


Author : Ambuj (MSFT), SQL Developer Technical Lead, Microsoft

Reviewed by : Naresh(MSFT), SQL Developer Technical Lead, Microsoft

Version history
Last update:
‎Jan 15 2019 12:51 PM
Updated by: