lsprivate

File still accessible through some directory version

The lsprivate listing for a file can include a version-extended path name to some directory element:

/usr/hw/src@@/main/3/subdir1/canUCme

In this example, file canUCme is stranded because its parent directory, subdir1, is not displayed in the dynamic view as it is currently configured; but the file can be accessed through version /main/3 of directory element src, which contains an entry for subdir1. (You cannot use this path name to access the view-private object. A version-extended path name can refer only to an element, branch, or version, not to a view-private file.)

To make a stranded file visible again, you must make its parent directory visible, by reconfiguring the dynamic view (in this case, to select version /main/3 of directory element src).

VOB is inactive

If a VOB is not currently active on your host, all view-private files corresponding to that VOB are temporarily stranded. lsprivate displays a warning message and prefixes a number sign (#) to path names within that VOB:

cleartool: Warning: VOB not mounted: “M:\jc_vw\jc_hw”
  VOB UUID is 1127d379.428211cd.b3fa.08:00:69:06:af:65
.
.
..
#M:\jc_vw\jc_hw\src\.cmake.state
#M:\jc_vw\jc_hw\src\findmerge.log.18-Mar-99.13:43:27
#M:\jc_vw\jc_hw\src\hello
#M:\jc_vw\jc_hw\src\hello.o
.
.
.

Reactivating the VOB on your host restores lsprivate command output to normal for pathnames within that VOB.

VOB is inaccessible

If a VOB has been unregistered, all view-private files corresponding to that VOB are temporarily stranded; if the VOB has been deleted, the view-private files are stranded permanently. lsprivate cannot distinguish these cases; it may infer the VOB's likely VOB tag, but it lists the view-private files with an Unavailable–VOB prefix:

cleartool: Error: Unable to get VOB object registry information for
  replica uuid "1127d379.428211cd.b3fa.08:00:69:06:af:65".
cleartool: Warning: VOB is unavailable -- using name: "<Unavailable-VOB-1>".
  If it has been deleted use 'recoverview -vob <uuid>'
  VOB UUID is 1127d379.428211cd.b3fa.08:00:69:06:af:65
  Last known location of storage is phobos:/usr/people/avid/tut/tut.vbs
#<Unavailable-VOB-1>/<DIR-3587d464.428211cd.b40c.08:00:69:06:af:65>
		/.cmake.state
#<Unavailable-VOB-1>/<DIR-3587d464.428211cd.b40c.08:00:69:06:af:65>
		/findmerge.log.18-Mar-99.13:43:27

The procedure for cleaning up stranded view-private files is described in the IBM Rational ClearCase Administrator's Guide.

Directory element has been deleted

If a directory element (or its entire VOB) has been deleted, all the corresponding view-private files are permanently stranded. They are listed with the VOB's UUID, as above, with no remedy possible, except to use recoverview to move the files to the dynamic view's lost+found directory (as described in the IBM Rational ClearCase Administrator's Guide).

The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.

The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.