IBM Support

About Evil Twins

Preventive Service Planning


Abstract

This technote explains what is meant by the term "Evil Twins" and provides guidance on how to identify and recover from evil twins in your IBM Rational ClearCase environment.

Content

About Evil Twins

"Evil twins" are two elements of the same name that have been created in different versions of the same directory element. When the directory versions are merged, it is not clear which twin has been lost, nor even that the twins may have different versions that need to be merged. The evil twin detection and prevention feature enables you to detect evil twins and suppress their creation. It also enables you to detect and locate existing evil twins.

Note: ClearCase 8.0 introduced new functionality to help you better manage Evil Twin elements where you will be able to more easily check a VOB for the presence of evil twins and setup your VOBs to warn or prevent their creation. Refer to the IBM DevOps Code ClearCase documentation under the topics of Managing "evil twins", protectvob and checkvob for further details.

Example:

DIR1@@/main/1 ==> foo.c added
DIR1@@/main/2 ==> foo.c rmnamed
DIR1@@/main/3 ==> foo.c added

Evil Twins are often created when two people add the same file to source control at the same time. ClearCase allows this to happen because the element is actually referenced internally by its OID (Object ID) and not its name.

Another kind of Evil Twins can occur on Microsoft Windows. The Windows operating system is case IN-sensitive (as opposed to UNIX and Linux which is case sensitive). This means that only one name regardless of case can exist in a single directory on Windows. To illustrate, open Windows Explorer and attempt to create the following files in a temp directory:

FOO.c

foo.c

You will be unable to do so due to how Windows manages file names.

The ClearCase MVFS can be configured to be case sensitive (Case-sensitivity and the MVFS)

By setting the MVFS to be case sensitive, you can then create files in a VOB in the same directory that have the same name differing only by case. 

For example, you can create the following files in the same directory:

FOO.c

foo.c

This is not a problem, so long as it is intentional and you are aware of the situation.

If you are not aware of the situation, it could be problematic.

For example, if you use a combination of Snapshot views and dynamic views on Windows and have a case sensitive MVFS setting, you could run into a problematic scenario:

For example:

dir1@@\main\1\FOO.c

dir1@@\main\1\foo.c

As Windows will only allow one of these files to exist in a directory space on Windows, ClearCase cannot load both into a snapshot view hosted on Windows.

Note: An eclipsed file is not the same as an evil twin, refer to Technote 329051 for more information about eclipsed files and ClearCase.

Locate Evil Twins

Now that you know what the identifying mark of an evil twin is, you can now takes steps to locate them in your VOB.

Use the cleartool find command to locate either FILE or DIRECTORY elements that "may be" evil twins.

Examples

If you run the following command from two views and compare the output (oid and pname), you can verify whether there is an evil twin situation on a directory level:

Windows:

cleartool find . -type d -exec "cleartool describe -fmt \"%On, %n\n\" \"%CLEARCASE_PN%@@\""

UNIX and Linux:

cleartool find . -type d -exec 'cleartool describe -fmt "%On, %En\\n" $CLEARCASE_PN@@'

If you run the following command from two views and compare the output (oid and pname), you can verify whether there is an evil twin situation on a file level:

Windows:

cleartool find . -type f -exec "cleartool describe -fmt \"%On, %n\n\" \"%CLEARCASE_PN%@@\""

UNIX and Linux:

cleartool find . -type f -exec 'cleartool describe -fmt "%On, %En\\n" $CLEARCASE_PN@@'

To locate an evil twin of an element in the current directory you can use either of the following command examples:

Windows:

Example 1:

cleartool find . -directory -ver !lbtype(NOTDEFINED) -exec "cleartool describe -fmt \"%On %n\n\" \"%CLEARCASE_XPN%/pname\"" 2>error.log | findstr /V "oid"

where:
pname = the name of the element
oid = the oid of the element

Example 2:

cleartool find . -directory -ver !lbtype(NOTDEFINED) -exec "cleartool describe -fmt \"%On %n\n\" \"%CLEARCASE_XPN%/element-pname\"" 2>null

The output of this command is as follows:

<element-oid> .@@\<current-directory-version>\<element-pname>@@

The redirection '2>null' is needed to filter away messages like:

cleartool: Error: Unable to access ".@@\main\pgosseli_p1\12\b.txt": No such file or directory.

If you have an evil twin, it would show up in this output as two different ObjectIds (oid).

First an example for file 'a.txt' in the current directory (showing no evil twins):

cleartool find . -directory -ver !lbtype(NOTDEFINED) -exec "cleartool describe -fmt \"%On %n\n\" \"%CLEARCASE_XPN%/a.txt\"" 2>null
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\3\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\4\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\5\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\6\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\7\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\8\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\9\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1\10\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1_ccrc\3\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\pgosseli_p1_ccrc\4\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\7\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\8\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\9\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\pgosseli_p1_2\0\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\pgosseli_p1_2\1\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\pgosseli_p1_2\2\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\pgosseli_p1_3\0\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\10\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\11\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\12\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\13\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\14\a.txt@@
8183ba8f.b9e14fd5.9406.34:b8:e8:4d:5f:26 .@@\main\p1_int\15\a.txt@@

Observations: The above output shows in the first column the 'oid' of the element named 'a.txt' in that specific version of the directory. This 'oid' is the same for all versions of the current directory, so there is no 'evil twin' of 'a.txt' in this directory.

Now an example for file 'b.txt' in the current directory (showing an evil twin):

cleartool find . -directory -ver !lbtype(NOTDEFINED) -exec "cleartool describe -fmt \"%On %n\n\" \"%CLEARCASE_XPN%/b.txt\"" 2>null
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\pgosseli_p1\3\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\pgosseli_p1\4\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\pgosseli_p1\5\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\pgosseli_p1\6\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\pgosseli_p1\7\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\7\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\8\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\9\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\pgosseli_p1_2\0\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\pgosseli_p1_2\1\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\pgosseli_p1_2\2\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\pgosseli_p1_3\0\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\10\b.txt@@
b5de3e4d.99c042f7.8f3c.53:87:cd:58:93:1c .@@\main\p1_int\11\b.txt@@
23d23b60.dde24dbe.9158.e4:26:18:2d:1c:ce .@@\main\p1_int\13\b.txt@@
23d23b60.dde24dbe.9158.e4:26:18:2d:1c:ce .@@\main\p1_int\14\b.txt@@
23d23b60.dde24dbe.9158.e4:26:18:2d:1c:ce .@@\main\p1_int\15\b.txt@@

Observations: For file 'b.txt' as seen in the above output there is an 'evil twin' condition. Observe that the 'oid' of the element 'b.txt' changes after .@@\main\p1_int\11. This is probably because the element was removed (rmname) from .@@\main\p1_int\11 and recreated (mkelem) again in .@@\main\p1_int\13

UNIX and Linux:

cleartool find . -directory -version "\!lbtype(NOTDEFINED)" -exec 'cleartool describe -fmt "%On %n\\n" $CLEARCASE_XPN/file.txt' > /tmp/file.out

In a bash shell run the following:

cleartool find . -directory -version '!lbtype(NOTDEFINED)' -exec 'cleartool describe -fmt "%On %n\\n" $CLEARCASE_XPN/file.txt' > /tmp/file.out

or

cleartool find . -directory -version \!lbtype\(NOTDEFINED\) -exec 'cleartool describe -fmt "%On %n\\n" $CLEARCASE_XPN/file.txt' > /tmp/file.out

Depending on your shell, with this command line, stderr will output to the screen. The results will be in the file /tmp/file.out

Confirm Evil Twins

The following steps need to be taken to confirm the existence of evil twins.

  1. When two files are found with the same name in two different versions of the directory, you can run the cleartool dump command to see if the files are in fact different elements.

    Example:

    foo.c ==> DIR1@@/main/1
foo.c ==> DIR1@@/main/3

    If you suspect foo.c may have an evil twin, run the cleartool dump <file@@> command for each file you suspect to obtain the object identifier (OID).

    Example:

    M:\dynamic_view\test_vob>cleartool dump foo.c@@

foo.c@@ (e7e4cd6a.e3f74b8f.b3ce.df:06:35:fe:a8:6c)
M:\dynamic_view\test_vob\foo.c@@
oid=e7e4cd6a.e3f74b8f.b3ce.df:06:35:fe:a8:6c   dbid=177 (0xeb82ef)
mtype=file element  type=12
stored fstat:
ino: 0; type: 2; mode: 0444
usid: NT:S-1-5-21-4179696171-2760821386-689065543-500
gsid: NT:S-1-5-21-4179696171-2760821386-689065543-1011
nlink: 1; size: 0
atime: Wed Dec 31 19:00:00 1969
mtime: Thu Oct 12 07:36:44 2006
ctime: Thu Oct 12 07:36:44 2006
returned fstat:
ino: 177; type: 2; mode: 0444
usid: NT:S-1-5-21-4179696171-2760821386-689065543-500
gsid: NT:S-1-5-21-4179696171-2760821386-689065543-1011
nlink: 1; size: 0
atime: Thu Oct 12 07:36:44 2006
mtime: Thu Oct 12 07:36:44 2006
ctime: Thu Oct 12 07:36:44 2006
master replica dbid=3
source pool=33  cleartext pool=35

    Note: You can use the Windows findstr command or the UNIX or Linux grep command to sort the results more effectively.

    M:\dynamic_view\test_vob>cleartool dump foo.c@@ | findstr oid
oid=e7e4cd6a.e3f74b8f.b3ce.df:06:35:fe:a8:6c   dbid=177 (0xeb82ef)

/view/test_vob%>cleartool dump foo.c@@ | grep oid
oid=e7e4cd6a.e3f74b8f.b3ce.df:06:35:fe:a8:6c   dbid=177 (0xeb82ef)

    Alternative to dump

    Instead of dumping the element, you could also run the following command from two views to compare the output:

    cleartool describe -fmt \"%On, %n\n\" <pname>@@

  2. Once you run the cleartool dump command for both files, compare the OIDs.

    Note: Be sure you run the dump command using the @@ extension after the file name. This denotes you are dumping the element. If you leave off the @@, you will dump the version (as opposed to the element), thus affecting your output.

    If the element OIDs are different but the names are the same, you have evil twins.

Recover from Evil Twins

If you discover evil twins in your configuration, it is important to address them as soon as possible.

You have two choices to resolve the problem.

  1. Rename one of the elements using the cleartool mv command.
  2. Remove one of the elements using the cleartool rmelem command.

Note: If in a UCM environment, you will need to first rename the element (using cleartool mv) and then remove the name using cleartool rmname. The reason is that removing elements in UCM using cleartool rmelem is not recommended as it can negatively affect your configuration. Review technote 73043 for more information about removing elements in UCM.

Prevention Triggers

The best solution used to control the creation of evil twins is to implement a pre-operational trigger during the mkelem/ add to source control operation.

The objective of the trigger would be to search the directory version tree for an element of the same name prior to creation of the new element.

In other words, the script used by the trigger will be required to look for two different files, with the same name, in two or more different versions of the same directory.

Note: Depending on the number of versions and branches on the directory, this could take some time, thus leading to potential performance degradation around the mkelem operation.

 

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSSH27","label":"IBM Rational ClearCase"},"ARM Category":[{"code":"a8m0z000000bngPAAQ","label":"ClearCase-\u003ECore"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.0.0;10.0.1;7.0.0;7.0.1;7.1.0;7.1.1;7.1.2;8.0.0;8.0.1;9.0.0;9.0.1;9.0.2;9.1.0"},{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSX33QT","label":"IBM DevOps Code ClearCase"},"ARM Category":[{"code":"a8m0z000000bngPAAQ","label":"ClearCase-\u003ECore"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"11.0.0"}]

Document Information

Modified date:
03 June 2026

UID

swg21125072

Page Feedback