Rational ClearCase FAQ: Essential cleartool Commands for Views, Branches, Labels, and Hijacked Files

Originally published on 2010-07-08; fully revised and updated.

If you work with Rational ClearCase and need fast answers for common operational tasks, this guide is for you. Based on the original FAQ, it consolidates high-value commands for finding view-private files, branch activity, checkouts, labels, and snapshot-view hijacked files.

What this FAQ helps you do

• List view-private files and checked-out items in a view.
• Find files by branch, label, date, and user.
• Report and scope checkouts using lsco options.
• Use label-focused config spec rules safely.
• Understand reserved vs unreserved checkout behavior.
• Detect and recover from snapshot-view hijacked file states.

ClearCase command quick reference

Find files and elements in a view

Run these in an appropriate VOB/view context. For syntax details, the original FAQ recommends cleartool man find and cleartool man lscheckout.

cleartool ls -r -view_only
cleartool ls -r -view_only | find ".java"
cleartool find -all -version "version(.../private_branch/LATEST)" -print
cleartool find . -type f -print
cleartool find . -type l -printCode language: PHP (php)

Find checkouts and recent activity

For branch-focused checkout reporting, lsco options change scope significantly:

cleartool lsco -brtype branch_name -r -l
cleartool lsco -brtype branch_name -r -l -cvi
cleartool lsco -brtype branch_name -r -l -me

ct lshistory -all -since 12-Jan-05
ct lshistory -all -since yesterday
ct lshistory -all -since yesterday -user mark

Query changes by date and label

The original FAQ includes examples for branch/date reporting and label-based diffs. Use branch, label, date, and user placeholders that match your naming conventions.

cleartool find -all -ver "brtype(test_3.1_main) && created_since(12-Dec-03.01:00) && !created_since(30-Dec-03)" -print
cleartool find -all -ver "brtype(ep_3.1_main) && created_since(12-Dec-03.01:00) && !created_since(30-Dec-03) && created_by(Mark)" -printCode language: CSS (css)

cleartool find -all -ver "version(.../integration_branch_name/LATEST) && !lbtype(LABEL_NAME) && !version(.../integration_branch_name/0)" -print
cleartool find -all -ver "lbtype(LABEL1) && !lbtype(LABEL_2)" -print
cleartool find -all -version "lbtype(MY_LABEL)" -printCode language: PHP (php)

Config spec example for selecting a label

This is the pattern shown in the original FAQ for loading labeled versions while keeping checked-out items selected first:

element * CHECKEDOUT
element * LABEL_NAME -nocheckout
element * /main/0Code language: JavaScript (javascript)

Interpretation: first select checkouts in your view, then select elements with the target label (without allowing checkout for that rule), then fall back to version zero for unmatched elements.

Reserved vs unreserved checkouts

ClearCase supports both exclusive and parallel checkout models. The difference matters at checkin time when multiple developers modify the same branch successor.

Hijacked files in snapshot views

In snapshot views, editing a loaded file without checkout can produce a hijacked state. The original FAQ recommends using ClearCase Explorer tools to inspect, compare, keep, or discard those edits.

flowchart TD
    A[Run Find Modified Files or Update View] --> B{Hijacked file found}
    B -- No --> C[Continue normal work]
    B -- Yes --> D[Compare with original version]
    D --> E{Keep local edits}
    E -- Yes --> F[Check out file]
    F --> G[Check in when ready]
    E -- No --> H[Undo hijacked file]
    G --> I[Update snapshot view]
    H --> I

• In ClearCase Explorer, right-click the snapshot view and run Find Modified Files.
• Right-click a hijacked file and use Compare with Original Version to inspect differences.
• If you want to keep changes, check out the file and proceed with normal checkin flow.
• If you want to discard changes, use Undo Hijacked File, then update the snapshot view.

Checked out but removed status

The original FAQ describes this state as: the VOB records an element as checked out, but the corresponding view-private checked-out file is missing. One common scenario mentioned is symlink-related behavior where target and link paths share underlying storage.

• Check symlink relationships first (Explorer path: Symlinks and target operations).
• Check in or uncheckout the symlink target element when appropriate.
• If not symlink-related, one recovery path is to uncheckout the element (work may be unrecoverable if no private copy exists).

cleartool unco path/to/file

Common pitfalls

• Running find or lsco outside the intended VOB/view context.
• Assuming ct alias exists everywhere; use full cleartool if needed.
• Forgetting that user IDs can be case-sensitive in history queries.
• Date expressions can be locale and format sensitive; validate with a narrow test first.
• Using Undo Hijacked File without backup can permanently discard local edits.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.