Arman Gungor's Blog Litigation Support and Technology


Preventing Field Results from Updating in Microsoft Word

Printing a Word Document correctly can be a hassle if you have fields that update automatically during printing. Fields are codes that instruct Microsoft Word to insert text, graphics, page numbers, and other information into a document automatically. For example, the { DATE } field inserts the current date and { FILENAME \p \* MERGEFORMAT } inserts the full file path into a document. To work around this issue, you can choose to lock certain fields:

  • To lock a field so that field results are not updated, click the field, and then press CTRL+F11.
  • To unlock a field so that field results can be updated, click the field, and then press CTRL+SHIFT+F11.


Filed under: Litsupport, Software 1 Comment

Turning off the Show Repairs Dialogue Box in Microsoft Word 2007

One of the common annoyances during batch processing of Word documents is the "Show Repairs" dialogue box. While most modern e-discovery applications dismiss such dialogues successfully, you may need to disable these pop-ups one day. Here is how:

Add a new DWORD value called "BulletProofOnCorruption" under HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Options and set it to 1.

While turning this dialgoue may come in handy for batch processes, I would recommend that you leave it active on your QC stations. It is important to know that there were errors detected in the native file during QC.


IPRO eCapture de-Duplication

IPRO_logoMany of you are familiar with eCapture as an ESI processing tool. It can be frustrating at times that you have to run a data extract or processing job on discovered material to be able to identify duplicates. What if you need to run a quick report prior to processing? If you are not de-duplicating compound documents (i.e. not maintaining compound document structure), then this is fairly easy. You go to the Items table in your eCapture database and de-duplicate the documents based on the MD5Hash column.

However, if you are looking to de-duplicate on an attachment family level, you will find that the FamilyHash column is not populated until a data extract or processing job is run. This is still not a big deal as you can create family level hashes outside and run your report. However, if you need to de-duplicate against a previous job, you will have to make sure that your family hashes are calculated exactly the same way as eCapture calculates them. As of version 4, eCapture calculates family hashes by individually hashing each document, concatenating the hash values in an attachment family in ItemID order and hashing the resulting string.

For example, if your attachment family consists of files F1, F2 and F3 (in ItemID order) with MD5 hashes H1, H2 and H3 and md5() is an MD5 hash function, the family hash value will be md5(H1&H2&H3).  Once you establish a workflow to do this efficiently, I would highly recommend running your own de-duplication outside of eCapture on a previous project and verifying the results.

Another important point to consider

When eCapture calculates family hashes, it combines the hashes of every item in the attachment family. This includes extracted embedded documents if the option is selected. This has two consequences worth considering:

1- If you are de-duplicating against a previous job where embedded document extraction options were set differently (i.e. jobs have a different number of extracted embedded items), eCapture will naturally produce different family hashes for the two attachment families with different extracted embedded item counts. This will obviously prevent the same original native document group to be de-duplicated, simply because it was handled differently during the two processing sessions.

2- I have also run into cases where extracting embedded items from the same file results in extracted items that look identical but have different MD5 hashes. This will also prevent two identical e-mail families from being properly de-duplicated against each other.

Filed under: Litsupport, Software 1 Comment

USB Write Protect

USB_Write_ProtectBeing in the litigation support industry, we work with USB devices almost every day. When working with customer-furnished data, it is very critical to prevent data spoilation by using a write-blocking device. Actions as simple as plugging the hard drive into a computer running Ms Windows and taking a look around are sufficient to alter metadata.

I recommend using OS independent, hardware based write blockers. The brands that I prefer are Tableau and WiebeTech. These products act as a bridge between your computer and the device that you are working with and block write requests at a hardware level while allowing you to read from the device.

Even though these devices are fairly affordable, unfortunately not every litigation support professional has one in his/her arsenal. There are different strategies for those of you who do not have access to such hardware. One of the easiest ways of blocking write requests to USB devices on a Ms Windows computer is by changing the storage device policy in the registry. The following key, starting with Windows XP Service Pack 2, controls whether or not Windows is allowed to write to USB devices:


I made a very small utility yesterday to automate this task and make it a little bit more user friendly. It is called USB Write Protect. All it does is to check whether or not you have a compatible operating system and to allow you to toggle the registry key mentioned above. Please feel free to download it via the link below and let me know if you have any questions or concerns. Please note the following:

  • This method blocks write access to USB devices that are connected after the registry key is set. In other words, you need to make sure the device you will be working with is disconnected prior to running USB Write Protect or changing the registry key manually.
  • This method only works with Microsoft Windows XP Service Pack 2 and up.

USB HD Download USB Write Protect 1.0 [140 KB]
Requires .NET Framework 3.5