打印

[TechNote] Type manager "text_file_delta" failed create_version operation（此文章被查看:5189次,被回复:3篇!! ）

懂你

管理员

Rank: 20

超级水手

楼主大中小发表于 2006-11-8 00:37 只看该作者

Type manager "text_file_delta" failed create_version operation

Problem

This technote provides a method to confirm the existence of a corrupt source container in an IBM® Rational® ClearCase® VOB based on a checkin error related to text files being referenced as a binary file along with steps to try and fix the container.

Cause

Attempts to complete a checkin results in the following error:

Error checking in 'M:\View\VOB\dir1\dir2\foo.c' text_file_delta: Error: "\\host1\share\vob_store\VOB.vbs\s\sdft\2b/38/0-36d0ebd89bc911d0a18400018080c4ee-4y" is not a 'text file': it contains a '\000'. This object's type does not support check-in of binary data.
Use a different type manager (such as compressed file). cleartool: Error: Type manager "text_file_delta" failed create_version operation. cleartool: Error: Unable to check in "foo.c".

If this error arises the first time checking in a file (or during a file import process), the file likely has a file extension suffix the cc.magic file would consider a text_file element type or the opening block of the file is in text but there are other parts of the file which contain binary data.

Cause 2

Check for indicators of a corrupt source container:

Confirm that the file in question is in fact a text file.
- Copy the file to the operating system (outside of ClearCase) and open with a text editor.
- Ensure there are no binary characters in the file.
Attempt to change the element type using the cleartool chtype command and retry the checkin. If the same error occurs during checkin, there is a problem with the source container.

Solution

Change the type manager of the file stored as text_file to a different type manager and checkin in the file.

Run cleartool chtype binary_file <filename> while the file is still checked out from /main/0

or
Remove the element (or rmname the element if this is a UCM environment) and change the file extension suffix to a binary_type element name.

Solution 2

Remove the corrupt source container:

Get the source container path for the element version using, cleartool dump -long <file name>
Try accessing the container using notepad:
- If an error occurs, proceed to the next step.
- If there is no error, then attempt to resolve the problem by running checkvob -fix -data <some_file.ext> against the file element.
  
  Note: If checkvob does not resolve the problem, then continue to the next step.
Move the container file to the local file system, completely outside the VOB storage. For example:

Windows®: move <dc-6114233f489e11d98859000180b152f5-sz> c:\tmp\test.txt

UNIX® and Linux®: mv <dc-6114233f489e11d98859000180b152f5-sz> /tmp/test
Create a new file to replace the corrupt source container that was moved.

Note: This file should be an empty file with the same name as the corrupt container, copied into the same directory path.
Run checkvob to recreate a new container file, checkvob -fix -data <build.xml>.

Note: This command will run against the empty container that was copied into the path to replace the empty container.
From the view where the checkin error was occurring, remove the version using cleartool rmver -xhlink <file name with complete branch and version tag>.

Example:

cleartool rmver -xhlink build.xml@@/main/Acqua2_new_integration/u663891_Aqua2_new_dev_st/2
Once the corrupt version is removed, you will be able to access the remaining versions to add new changes to source control.

Note: You will need to repeat these steps if any additional versions continue to give the same error on checkin.