CODEWITHSUNDEEP
clearcaseclearcase-ucm
user2636464
user2636464

Reputation: 735

not able to access checkout or checkin file in clearcase

I am not able to deliver one of the files in clearcase from dev stream to int stream. It failed and I did a undo checkout on int stream and it created a zero version . Now I cannot checkout the file and it says Error: checked out the the file but could not copy data. unknown vob error.

I checked out and overwrote with another file and tried checkin and it says. checkin failed: not a BDTM container

I tried to delete the zero version and branch and it says cannot delete - not a BDTM container

I cannot open the file as well where it says no such file or directory. I can see versions on other branches but not this zero version

I got this ibm support page but it did not help me. http://www-01.ibm.com/support/docview.wss?uid=swg21294695 Please advise.

Upvotes: 1

Views: 809

Answers (1)

Brian Cowan
Brian Cowan

Reputation: 1073

A Binary Delta Type Manager container has a couple of details you need to be aware of:

  1. It is stored as a gzipped file containing delta data, which is partially text and partially binary.
  2. There is one container per branch with an existing version > 0.
  3. The ...\branch\0 version (with the exception of \main\0) actually uses the container of the parent branch.

So, what does this mean in reality? You have at least one corrupt source container.

  • If you are checking out ...\branch\0, it is the container for the PARENT branch that is damaged. Do a cleartool dump on the parent version to get the container path, then skip down below
  • If you are checking out ...\branch\1 or later, dump the version you are trying to check out to get the source container path. Then...

Examine the file data and metadata:

  • If it's < 47 bytes (the minimum size of a .gz file), it is corrupt. If it's 0 bytes, then something interfered with the checkin process.
  • If it is larger, attempt to decompress it using gzip -d < {file path} > temp.txt, then open the file in a text editor. It should have a header containing a lot of version OID's and the like...
  • If gzip errors out, without decompressing the file at all, open the file and examine it's contents. It likely does not contain compressed data.
  • If gzip errors out with data integrity or premature-EOF errors, you most likely have a filesystem issue that damaged the file.

The resolution is going to be to either replace the container from backup, a remote replica, or to "ndata" the versions. This is not something that is best discussed on StackOverflow, but rather through a PMR.

Upvotes: 2

Related Questions