Tips: Watch the DFC Registry Mode

I know that I owe a post on SharePoint and EMC World. I just keep getting sidetracked with these simple, easy, yet relevant topics. As much as I may wish it, project work continues even as we are prepping for the future of the Documentum world. In addition, it has been a while since I posted a Documentum Tips article.

This issue is something that, while not necessarily new in D6, is more relevant in the D6+ world that we are living in these days.

What is the DFC Registry?

To quote the file:

On Windows clients, DFC uses the system registry to keep track of files checked out or exported to the client machine. On Unix systems, DFC keeps this information in a file on file system. DFC sets this mode automatically.

Essentially, when you interact with content on your system with a local DFC client, the information is tracked locally to optimize communications between the DFC client and the Content Server. The key setting, dfc.registry.mode, determines if the registry information is store in the Windows Registry, windows, or locally in the file system, file.

If you are in a non-Windows machine, like Solaris and AIX, then this issue may not impact you as you will always have the file-based registry in operation.

No Installation Needed

One of the nice features of D6 is the ability to deploy Documentum applications without installing any Documentum software. The most work that I have had to do is modify the file to point to the proper DocBroker. That is, until today when we saw this message:

Exception in thread “main” java.lang.UnsatisfiedLinkError: no DfRegistryWin32 in java.library.path

Initial research directed us to some artifacts that screamed pre-D6. I was about to break down and just install the DFC client locally on the system when it hit me. The Registry! I had seen the setting in and decided to try changing it. The following two lines were placed, as is, in our configuration:

dfc.registry.file = ${}/documentum.ini
dfc.registry.mode = file

That did the trick! Not hard, once you know what to do.

What Had Happened?

The next question was, Why did we have to do this now? We quickly determined the reason. Every previous machine that had run this particular application, and most of our applications for that matter, had previously been installed with some version of the Documentum DFC. As such, the base Windows registry entries had already been placed in the Windows registry. In addition, the DLL used to interface between the JVM and the Windows operating system was also present.

So when the DFC had tried to write to the Windows registry, everything was in place. When we placed the application onto a “pristine” machine, without changing our DFC Registry Mode, we hit the error.

Now we know. We will most likely install the DFC on all Production servers so we can use the Windows registry instead of a flat file approach.

If you have different experiences, leave a comment and let everyone know.

8 thoughts on “Tips: Watch the DFC Registry Mode

  1. Bindu, great to see you in the blogsphere. It has been some time. It is a great post and I encourage people to go and read it. Bindu’s post explains how the registry works in more detail.

    If you want to understand the DFC registry, as opposed to just keeping it out of your way, read it.


  2. Victor Spivak says:


    Good job. We should add this information to our documentation. I will forward your post to our tech pubs.


  3. Victor, thank you for chiming it. It is good to know that the team back in Pleasanton occasionally reads the stuff out here in the blogsphere and that it can positively impact things at EMC.


  4. Pie,
    Good explanation.
    I have a point to add, if we still want to use Windows Registry (on Windows client) we need to add DfRegistryWin32.dll to java.library.path. The reason being the Windows registry was already holding the information about the previously checked out, Viewed documents entries.
    If all of a sudden we change the registry mode of DFC consider the a case of a previously checked out document. When I try to checkin, DFC will not be unable to find the checkout related information (as new registry has no information of the location of the checked out file).
    This may fail the checkin operation.
    In a WDK(UCF based) scenario changing the registry.mode from windows to file will prompt for the checked out files location, if it doesn’t find in the registry.


  5. All true Rajendra. I wouldn’t recommend switching in mid-stream.

    The situation above was purely rolling a mid-tier application to a new server, and the complaints that followed.


  6. Laurence, Thanks for sharing this tip on your blog. You literally saved me from a really stressed out weekend.

    We are preparing to migrate some 70,000 documents from one Lotus Domino to Documentum using a custom DFC application. We were in the process of setting up around 20 laptops with this custom application. The application kept crashing without any error on some of the laptops while it ran perfectly on others. It was really puzzling. After reinstalling DFC and JDK several times, I enabled the tracing in DFC, ran the application and then I saw the DfRegistryWin32 related error in the logs. I Googled for it and landed straight at this post. Thanks to Google and to you for sharing this info 🙂
    – cheers


Comments are closed.