IBM Support

Unable to checkout file by version extended pathname, view_lookup_ext failed

Troubleshooting


Problem

This technote explains why attempts to checkout an IBM® Rational® ClearCase® element using the version extended pathname results in the error []view_lookup_ext failed[] and provides suggestions to resolve the issue.

Cause

Attempts to checkout a file using the version extended pathname results in the error:

M:\std_view\program>cleartool co -nc M:\std_view\program\.@@\main\br_1\10\hidden\main\br_1\1\file.txt@@\main\br_1\1

cleartool: Error: Operation "view_lookup_ext" failed ("M:\std_view\program\.@@\main\br_1\10\hidden\main\br_1\1\file.txt"): Invalid argument.
cleartool: Error: Unable to check out "M:\std_view\program\.@@\main\br_1\10\hidden\main\br_1\1\file.txt".

This type of situation is typically encountered when running a search for specific files and/or branches within a VOB as such:

M:\std_view\program>cleartool find . -all -name "file.txt" -version "version(.../br_1/LATEST)" -print
M:\std_view\program\.@@\main\br_1\10\hidden\main\br_1\1\file.txt@@\main\br_1\1


The primary cause of this problem is that there is no current directory entry for the file or directory from which to create the checked out file.

In this case there are three versions to be concerned with:

  1. The first is the directory version which contains the hidden directory.
  2. The second is the version of the hidden directory which contains the actual file
  3. The third is the version of the file you wish to checkout.


This is true even though you can access the contents directly using the version extended pathname:

M:\std_view\program>type M:\std_view\program\.@@\main\br_1\10\hidden\main\br_1\1\file.txt@@\main\br_1\1
This is a test file
Called file.txt
It's in it's own version
Of the parent directory


You cannot check it out because there does not exist a current entry within the version selected of the directory itself, nor does the hidden directory exist within your own view structure.

Resolving The Problem

There are three different methods that can be used to correct this problem:

  1. You can modify the config spec to pick a valid version of the directory, hidden in this case, which holds the entry of the file. This would be easier in large nested environments where directory branches house specific sub-directories.

  2. You can traverse to the file in question in order to check out the file:
    1. Check out the current directory version to reveal the hidden directory:

      M:\std_view\program>cleartool co -nc .@@\main\br_1\10
      cleartool: Warning: Version checked out ("\main\br_1\10") is different from version selected by view
      before checkout ("\main\19").
      Checked out "." from version "\main\br_1\10".

    2. Check out the hidden directory to reveal the file itself:

      M:\std_view\program>cleartool co -nc hidden@@\main\br_1\1
      cleartool: Warning: Version checked out ("\main\br_1\1") is different from version selected by view
      before checkout ("\main\0").
      Checked out "hidden" from version "\main\br_1\1".

    3. Finally, check out the version of the file you want:

      M:\std_view\program>cleartool co -nc hidden\file.txt@@\main\br_1\1
      cleartool: Warning: Version checked out ("\main\br_1\1") is different from version selected by view
      before checkout ("\main\0").
      Checked out "hidden\file.txt" from version "\main\br_1\1".

  3. You can delete the element using its object identifier string (OID). The OID is the unique identifier ClearCase uses in the background; it remains even after you rmname an element. If you can pull up at least some version of the named element, you can find the OID and delete the element based on this OID:

    1. Run cleartool dump <filename>@@ to get the element's OID.
    2. Run cleartool rmelem oid:<oid> to remove the element.
Example:

$ cleartool dump foo.pl@@

foo.pl@@ (da24c368.5e1711db.8978.00:b0:d0:b6:e6:82)
/vobs/vob_tag/foo.pl@@
oid=da24c368.5e1711db.8978.00:b0:d0:b6:e6:82  dbid=109 (0x6d)
mtype=file element  type=9
...

$ cleartool rmelem oid:da24c368.5e1711db.8978.00:b0:d0:b6:e6:82
CAUTION! This will destroy the element, all its branches and versions,
including all data, meta-data and history, and will remove the element
from all directory versions that now contain it.  Once you destroy the
element, there will be no way to restore it to its current state.
If you want to preserve the element, but remove references to it from
future directory versions, use the "rmname" command.

Element "/vobs/vob_tag/foo.pl" has 1 branches, 2 versions, and is entered
in 1 directory versions.
Destroy element?  [no] yes
Removed element "/vobs/vob_tag/foo.pl".

Note: It is dangerous to script the removal of elements due to the risk of accidental deletion. Rational Customer Support has no way to restore a lost element from a VOB; the only option would be restoring the VOB from backup or replica.


[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"VOB","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF015","label":"IRIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"2002.05.00;2003.06.00;7.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
16 June 2018

UID

swg21135439