SERIOUS: Extracted archive and cache files differ for filename.h-23:incl:DCM#1:
Cache file path: database_path/st_root/cache/source/#28/149628
Cache file size: 6228
Extracted file path: database_path/st_root/tmp/check/filename.h_UBAABLII
Extracted file size: 12367
Archive path: archive/source/incl/ccm_rcs/DCM#1/20/filename.h,v
この例では、ccm fs_check コマンドによってアーカイブから抽出されたソースが、同じオブジェクト・バージョンのキャッシュ・ファイルと一致していません。さらに、ファイルのサイズも異なります。オブジェクト・バージョンの所有者は、これらのソースを比較して、どのバージョンが正しいかを判別する必要があります。
> del database_path/st_root/cache/source/#28/149628
> ccm cat filename.h-23:incl:DCM#1 > nul
キャッシュ・ファイルが正しい場合は、影響を受けるオブジェクトの 4 つの部分から成る名前をこのテキスト・ファイルに追加します。その後、ccm archive_fix コマンドを実行し、キャッシュ・ファイルを使用してアーカイブを再作成します。
ccm archive_fix コマンドの実行方法について詳しくは、『アーカイブ変換に関するよくある質問 - fs_check コマンド』を参照してください。サポートが必要な場合は、IBM® Rational サポートに連絡して、ccm fs_check のログ出力を提供してください。
アーカイブが欠落しているか、または破損しています。キャッシュ・ファイルが正しい場合は、影響を受けるオブジェクトの 4 つの部分から成る名前をこのテキスト・ファイルに追加します。その後、ccm archive_fix コマンドを実行し、キャッシュ・ファイルを使用してアーカイブを再作成します。
ccm archive_fix コマンドの実行方法について詳しくは、『アーカイブ変換に関するよくある質問 - fs_check コマンド』を参照してください。
データベース・メタデータのオブジェクトのソース属性が欠落しています。ソース属性を再作成すると、この問題が解決することがあります。ただし、破損を完全に修正するには、追加の手順が必要な場合があります。
影響を受けるオブジェクトに適切なタイプを指定して、ソース属性を再作成する必要があります。例えば、プロジェクト・タイプのオブジェクト (myproject-2:project:1) についてこの問題が報告された場合は、次のコマンドを実行して、欠落しているソース属性を作成します。
% ccm attr -create source -t project myproject-2:project:1
ディレクトリー・タイプのオブジェクトの場合、欠落しているソース属性は次のようになります。
% ccm attr -create source -t dir mydir-2:dir:1
プロジェクト・タイプまたはディレクトリー・タイプのオブジェクトのキャッシュ・ファイルは、常に長さがゼロのファイルです。欠落しているソース属性を作成して、この破損を修復します。キャッシュ・ファイルの長さがゼロであることを確認してから、ccm archive_fix コマンドを実行してアーカイブを再作成します。
ccm archive_fix コマンドの実行方法について詳しくは、『アーカイブ変換に関するよくある質問 - fs_check コマンド』を参照してください。
ただし、この破損の修復は、常にこのように単純であるとは限りません。ASCII タイプのオブジェクトの場合、ソース属性にはオブジェクト・バージョンの実際のソースが含まれています。バイナリー・オブジェクトの場合、ソース属性にはキャッシュのパスが含まれています。疑問がある場合は、IBM Rational サポートに連絡してください。
オブジェクト・バージョンが非静的です。つまり、チェックインされていません。そのため、アーカイブがありません。
ワークエリアにオブジェクト・バージョンのソースのコピーがある場合は、ccm_root でキャッシュ・ファイルを作成します。
% touch database_path/st_root/cache/source/#56/123456
続いて、ソースをワークエリアのファイルからキャッシュ・ファイルにコピーします。ただし、ワークエリアのコピーがない場合は、% touch database_path/st_root/cache/source/#56/123456 を使用して空のキャッシュ・ファイルを作成する必要があります。その後、オブジェクト・バージョンを削除するか、このオブジェクトの別のバージョンのソースをキャッシュにコピーします。
変更されたオブジェクト・バージョンに関連付けられているすべてのタスクが現在も正しいことを確認します。キャッシュ内のオブジェクト・バージョンのソースを置き換えた場合、タスクを変更するか、タスクとオブジェクト・バージョンの関連付けを解除する必要があります。そうすることで、タスクのオブジェクト・バージョン・コード内に、作業の正確な説明が格納されます。
name-version:type:instance の内部アーカイブ情報は、アーカイバー、ID、およびパスの 3 行のみとする必要があります。アーカイブが破損しています。ccm archive_fix コマンドを実行し、使用可能なキャッシュ・ファイルを再作成する必要があります。
ccm archive_fix コマンドの実行方法について詳しくは、『アーカイブ変換に関するよくある質問 - fs_check コマンド』を参照してください。
システムが、name-version:type:instance のアーカイブ・ファイル・パスを判別できません。ソース属性が破損しています。属性を手動で設定してください。ccm archive_fix コマンドを実行して属性を検証する前に、キャッシュ・ファイルのパスを取得します。キャッシュ・ファイルのパスの形式は以下のとおりです。
database_path/st_root/cache/source/#last 2 digits of cvid/cvid
現在のデータベース内にあるこれらのオブジェクト・バージョンそれぞれに対して、固有の cvid が必要です。
% ccm prop name-version:type:instance –f %cvid
ccm attr –d source name-version:type:instance
ccm attr –c source –t ascii –v “database_path/st_root/cache/source/#last 2 digits of cvid/cvid” name-version:type:instance
すべてのオブジェクト・バージョンに対して、この手順を繰り返します。それぞれの固有 ID を使用してください。続いて、ccm archive_fix コマンドを再実行して、すべてのエラーが修正されていることを確認します。サポートが必要な場合は、IBM Rational サポートに連絡してください。