Clearcase Technical blog

General musings on Clearcase

Understand about the .copyarea.db and .copyarea.dat files

How are the .copyarea.dat and .copyarea.db files are used in an IBM® Rational® ClearCase® Remote Client (CCRC) or ClearCase Web (CCWeb) view.

Each CCRC or CCWeb view root directory (the directory tree where the files from the VOB are downloaded into the local view workspace) contains a .copyarea.dat and a .copyarea.db file. Below is a brief explanation of how these files are used.

.COPYAREA.DAT
The .copyarea.dat file is used to detect if changes have been made to the loaded files to determine is hijacked state.
The .copyarea.dat file stores information like:
• When a view was created
• What http server the view was originally connecting to
• The view's Operating System platform
• CCRC remote view tag

The contents of a .copyarea.dat file looks similar to the following:

ClearCase CopyArea|222|ed364ca8f7ee468185bfa528784055ed|a:Windows XP|1c:Thu Mar 10 12:24:08 EST 2005|base|1f:htp://host1/ccase/bin/ccweb.exe|b:user1_host1|20

.COPYAREA.DB
The .copyarea.db file is created in each directory of a CCRC or CCWeb view which contains a list of files that are loaded in the view as well as metadata about the files.
If this file is missing or corrupt, you will notice that all or some of the loaded files will appear to be hijacked.
Also, CCRC and CCWeb keep a record of both the timestamp and a checksum for each element version downloaded. This information is stored in the .copyarea.db file in each directory.
The contents resemble something like:
ClearCase CopyAreaDB|4my_test_vob217:foo.doc|1|1028d7f8806|6000|89a7d530|cc22d419b775452ea0da8bf1b807c616|0

or
ClearCase CopyAreaDB|4
.
2
1
5:testvob|2|0|0|0|cb9bf50026fe43ef96160518044e8c93|0

The CCRC and the ClearCase Web use the following algorithm to detect if a file has been changed:
1. First, the file size is checked. If the file size has changed, then the file has been hijacked.
Next, the file's timestamp is checked. If the timestamp has changed, then the CRC of the file is checked. If the timestamp AND the CRC of the file have changed, then the file has been hijacked. If only the timestamp changed, but the CRC is still the same, then the new timestamp is updated in the copyarea.db.