Cleanup ClearCAse lost+found

[Kevin Duckett]

I have this situation with orphanded ClearCase files and directories.

Below are some files and directories in the lost+found directory of one of our
VOBS.

-r-xr-xr-x 1 chengy canis 0 Mar 16 13:37
sendMOTD.ksh.3d4a9351dbd011d2b3110001808d03ac*
drwxrwxrwx 2 rational canis 0 Mar 16 08:28
src.21797272dba511d2a6b60001807917d5/
-r-xr-xr-x 1 chengy canis 0 Mar 16 13:36
startLookup.315a9301dbd011d2b2f60001808d03ac*
-r-xr-xr-x 1 chengy canis 0 Mar 16 13:37
startPublic.3a4a933cdbd011d2b3080001808d03ac*
-r-xr-xr-x 1 chengy canis 0 Mar 16 13:36
startQuery.345a9315dbd011d2b2f90001808d03ac*
-r-xr-xr-x 1 chengy canis 0 Mar 16 13:36
startUpdate.375a9328dbd011d2b2fd0001808d03ac*
-r-xr-xr-x 1 chengy canis 0 Mar 16 13:37
stopFdbm.ksh.388a9331dbd011d2b2fe0001808d03ac*
-r-xr-xr-x 1 wernerc canis 0 Apr 1 07:57
where.txt.75ddb351e83311d2b93400018075b0b9*
-r-xr-xr-x 1 wernerc canis 0 Mar 31 12:19
WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9*

We need to clean this up but have been unsuccessful in our attempts. We have
tried the following:

1) cleartool rmelem -f file_name
result:
cleartool: Error: Can't delete element with checked out versions.
cleartool: Error: Unable to remove element
"WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".

We found where the checked-out version is by running a checkout report on the
VOB:

31-Mar.12:19 wernerc checkout version
"/net/chessie/opt2/rational/vobs/gtn_web/lost+found/WHERE_PRO_SECONDARY.dbb96466
e78d11d2b51200018075b0b9"
from /main/integration_test/maint_5.0_web/0 (reserved)

But it points to the lost+found directory. How would one cancel this type of
check-out?

2) cleartool rmname file_name
result:
cleartool: Warning: Object
"WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".
Removed "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".

But the file is never removed in this case even though the message says it's
removed.

--
Kevin

[Dwain Wilder]

You need to use the uncheckout command to remove the checkout.
Then use rmname. Do _NOT_ use rmelem unless you want to remove
the entire history of this element from the database. Presumably,
your element had some function in the past. Using rmname preserves
this history and only removes it from the lost+found directory.

(See notes below)

cleartool unco WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9

>
> 2) cleartool rmname file_name
> result:
> cleartool: Warning: Object
> "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9" no longer referenced.
> cleartool: Warning: Moving object to vob lost+found directory as
> "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".
> Removed "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".
>
> But the file is never removed in this case even though the message says it's
> removed.

You need to remove the filename as it exists in the lost+found directory.
Otherwise, if you try to rmname WHERE_PRO_SECONDARY.dbb ,it will be
simply send it back to lost+found, because clearcase still thinks it is a stranded
element:

cleartool rmname WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9

HTH
Dwain

[Kevin Duckett]

Of the directories, running lshistory to determine where they were exactly
checked-out from doesn't work. Noting is displaye. Of the files, it doesn't give
the path string where the files are in the dicectory structure.

Dwain Wilder <Dw...@bearmeadow.com> wrote in message
news:374B24C8...@bearmeadow.com...

[Sid Pollock]

Kevin Duckett wrote:

> 2) cleartool rmname file_name
> result:
> cleartool: Warning: Object
> "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9" no longer referenced.
> cleartool: Warning: Moving object to vob lost+found directory as
> "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".
> Removed "WHERE_PRO_SECONDARY.dbb96466e78d11d2b51200018075b0b9".
>
> But the file is never removed in this case even though the message says it's
> removed.
>

> --
> Kevin

When it reports that it cannot be removed because it is checked out then you need to
find out
to what view it is checked out. You can do so using lsvtree. As the administrator,
start up that view and uncheck it out.

In our company we have found that developers never realize, or care, what's in
lost+found. In fact, we restrict the rmelem command so they cannot remove elements
explicitly and, thus, shoot themselves in the foot. Elements that end up in
lost+found typically represent new elements which first appeared in a directory
which was checked out and then unchecked out. i.e. check out the directory, add new
files or subdirectories, uncheck out the directory ---> the new files or
subdirectories end up in lost+found. As a result, the administrator simply does an
rmelem of the objects listed in the lost+found since it is highly likely that no one
cares about these orphaned/new elements. Some of these elements, themselves, could
be in a checked out state and so need to be unchecked out as described in the above
paragraph.

Note that if you rmelem a directory from lost+found and it has elements that only
exist in that directory version then these elements will find their way into
lost+found. This can re-occur several times as there could be sub-directories under
sub-directories, etc. Hence "Warning: Moving object to vob lost+found directory".
Eventually, you will arrive at no more elements to rmelem.