Windows Live Mesh - NAS Synchronization

Summary

I use Windows live Photo Gallery (it's awesome) to manage my photos. I recently bought a NAS device to store all of my media and found out that Photo Gallery is now substantially slower at detecting newly added images and recognizing faces. My guess is it has something to do with the overhead in pulling images off the network. As a solution I decided I would download Windows Live Mesh (WLM) and use the folder synchronization to keep local copy of the files on my box. It turns out that WLM does not support synchronization of folders on a NAS. Luckily, the Microsoft Sync Framework guys have made it really simple to roll out you own solution.

Details
The Microsoft Sync Framework defines a basic set of functionality that must to be provided in order to synchronize information from different data sources (AKA replicas). head over to http://msdn.microsoft.com/en-us/sync/default.aspx to get some more information. There documentation is improving... at least compared to when i looked at it a year ago.

By default the sync framework comes with a handful of replica providers, one being a file synchronization provider. below is a snippet of code from the application I am writing that performs the synchronization to my NAS.

1:  using (var sourceProvider = new FileSyncProvider(SourceDirectory.FullName, SyncFilter, SyncOptions))
2:  using (var destinationProvider = new FileSyncProvider(DestinationDirectory.FullName, SyncFilter, SyncOptions))
3:  {
4:     SyncOrchestrator agent = new SyncOrchestrator();
5:     agent.LocalProvider = sourceProvider;
6:     agent.RemoteProvider = destinationProvider;
7:     agent.Direction = SyncDirectionOrder.Upload;
8:     sourceProvider.DetectChanges();
9:     destinationProvider.DetectChanges();
10:    agent.Synchronize();
11:  }

Although there is a lot of context missing around this code, this is the core of what gets a synchronization session done. In order to perform synchronization between two replicas you must have a source provider and a destination provider (lines 1 and 2). For file synchronization, the sync framework 4.0 provides the FileSyncProvider class. On line 4 a sync orchestrator is constructed. This object controls the interaction and flow of communication between the two providers. Line 8 and 9 are optional depending on the sync options provided in the provider, but essentially this tells the provider to make sure the replicas they represent are up to date with their knowledge (what files were changed, when, etc). There is a bit of overhead for file system providers so I decided to manually execute this. In the actual code implementation, there is some progress notifications associated with detecting changes. Line 10 tells the agent to start the synchronization. I was pretty impressed with how simple this was to setup. I put my current project up on codeplex if you want to take a look, or even better let me know if you want to contribution rights. I am going to add a couple final features, but it is mostly meeting my basic requirements.

Code was a quick write, let me know if you are interested in something and I will try to add it. I hope to have enough time to actually make this thing more usable over the next month. Currently I just have it setup as a windows scheduled task to perform my sync nightly… or I can always manually run it. download and compile from http://foldersyncer.codeplex.com/

Hopefully the Mesh team enables NAS sync as I am positive it will go through a whole host of testing that I did not do.

SmartCard – PC/SC SCardConnect Sharing Violation

Summary:

Windows 7 connects a smart card with exclusive rights, causing SCardConnect PC/SC calls to fail with shared or exclusive rights. After about 10 seconds, the exclusive connection is released and SCardConnect succeeds. To fix, just disable a bunch of policy settings (read the details) :).

The Details:
I have been working on an abstraction layer for our smart card communication here at Eid for a while. The code allows us to easily swap out readers without any concern for how communication with the reader occurs. It also provides a very simple and clean interface for querying a card for capabilities and features.

We just switched from a reader that uses a proprietary Magtek MCP API to the more standard PC/SC API. Although we already had support for PC/SC communication, Today we switched back to using a reader based on PC/SC and all of a sudden our application was failing to connect to our Smart Card on windows 7 boxes. Previously all testing had been done in a Windows XP environment. The behavior we were seeing was that the SCardConnect API call was failing with a sharing violation for about 10 seconds after a card was inserted. After the 10 seconds passed, we would suddenly be able to successfully connect to the card.

It turns out there are a number of Local Group Policy Settings that control the behavior windows will take when a card is inserted (particularly a card that has a WHQL certified driver). I have pasted a screenshot of the settings below that control the behavior. you can run gpedit.msc to get this mmc terminal up. For more info on these settings, visit the smart card help pages on msdn @ http://technet.microsoft.com/en-us/library/ff404287(WS.10).aspx