Windows 8.1 Installer Folder Cleanup

On my Windows 8.1 laptop with a small SSD (100GB), disk space was running out. When I checked disk usage by folder using TreeSize, I found that C:\Windows\Installer was taking up over 22GB! A quick online research revealed that I couldn’t delete files from this folder safely. However, I also learned that it could be holding files that were no longer in use or needed.

On further search, I found this neat little utility called Patch Cleaner, which looks for such unused files and gives you the option to delete them or back them up to another location. When I ran it, I found that about 15GB out of those 22 were being hogged by the files that were no longer needed! All of these 400+ unused files are MSP files. I have moved these files to an external hard disk just in case there is an issue later. Restoring the files is as easy as copying them back to the installer folder.

Thank you Patch Cleaner for freeing up over 15% of my disk space!

Advertisements

Cleaning up Locales

DISCLAIMER: The following ideas may not be considered as advice for any purpose, whatsoever. I assume absolutely no liability if any of the following ideas are used for any purpose. Any experimentation related to the following ideas is best done in a completely disposable test environment.

EMC has a an excellent document about Adding Locales to Documentum WDK-based Applications. It explains how to add locales when you want them and how they are used. It also explains what happens in the repository and what needs to be done on the WDK side.

However, it didn’t help when we encountered some weird issues. First, we noticed that on the File > Import screen, the type dropdown had lost all the labels. So the values looked like “dm_document (dm_document)” rather than “Document (dm_document)“. Research on the issue led us to locales in the repository. We found “en,en_GB” on dm_docbase_config.dd_locales. Further, the data dictionary had en_GB records which had labels set to be the same as the type names. We had no information about how en_GB got added in the first place since there hadn’t been a business need to do so. We suspected one or more more docapps related to a product originating in Europe to be the source of the additional en_GB locale.

It got more interesting when we removed en_GB from dm_docbase_config.dd_locales. Webtop File Import continued to behave as if it didn’t matter what dm_docbase_config.dd_locales was set to. It turned out that we had discovered a Webtop bug! Content Server clients must first look at what is set on dm_docbase_config.dd_locales before looking at the data dictionary contents.

It may take a service pack or hotfix to get the bug fixed. In the meantime, we could fix the problem if there was a way to clean up data dictionary for the unwanted locale.

There are multiple ways to address this, with varying degrees of effort and risk involved. These are described below.

Before using any ONE OF THE FOLLOWING options, dm_docbase_config.dd_locales needs to be set to 'en'. This can be done through DA using the UI or through DQL/API.

1. [WDK] Get EMC to provide a hotfix for Webtop. This may take a while and the fix will need to be applied to all the Webtop instances, customized or otherwise.

2. [WDK] Implement a WDK customization to address this problem. Other than the development effort, this option is similar to 1.

3. [SQL] THIS IS A DB CHANGE AND A DATA BACKUP IS THE SMART FIRST STEP.
Copy the label_text from 'en' records (dmi_dd_type_info_sp, dmi_dd_attr_info_sp) to the corresponding 'en_GB' records where label_text = type_name. This will lead to the same label on the UI no matter which locale is used – the exception will be the labels for any type that are already set in en_GB. For completeness, both dmi_dd_type_info_sp and dmi_dd_attr_info_sp should be updated.

Publish data dictionary.

3. [SQL] THIS IS A DB CHANGE AND A DATA BACKUP IS THE SMART FIRST STEP. THIS IS PROBABLY NOT SUPPORTED BY EMC.
Rename the nls_key attribute from 'en_GB' to something like 'xx_XX' (dmi_dd_type_info_sp, dmi_dd_attr_info_sp).

Publish data dictionary.

4. [SQL] THIS IS A DB CHANGE AND A DATA BACKUP IS THE SMART FIRST STEP. THIS IS PROBABLY NOT SUPPORTED BY EMC.

Delete records where nls_key = 'en_GB' (dmi_dd_type_info_sp, dmi_dd_attr_info_sp).

Publish data dictionary.

4. [SQL] THIS IS A DB CHANGE AND A DATA BACKUP IS THE SMART FIRST STEP. THIS IS PROBABLY NOT SUPPORTED BY EMC.

This option is relatively cleaner (probably “too clean” in certain ways) but creates additional work. The first step will cause you to lose data dictionary records for custom types and custom attributes. These can be restored by reinstalling the docapps containing this information. Watch out for couple of risks:
a) If it was one of these docapps that introduced the undesired locale, that will be reintroduced.
b) Make sure that any lifecycles, workflow templates etc. in the docapp are not versioned unintentionally.

Truncate tables:
dmi_dd_common_info_s
dmi_dd_common_info_r
dmi_dd_type_info_s
dmi_dd_type_info_r
dmi_dd_attr_info_s
dmi_dd_attr_info_r

Publish data dictionary. It is probably a good idea to do this through the job and wait for the job to finish. It may take some time but it will restore the default 'en' locale.

Reinstall any custom docapps carefully.