1

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.

user2636464
  • 685
  • 7
  • 17
  • What version of ClearCase are you using? Still a CC 8 since 2015? (https://stackoverflow.com/q/29113558/6309) Is it a multi-site one? – VonC Dec 29 '17 at 10:49
  • YES cc8. but not the one you have linked above. I have moved on to a different place now. – user2636464 Dec 29 '17 at 12:36

1 Answers1

2

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.

Brian Cowan
  • 1,048
  • 6
  • 7
  • So this is an xml file with version branch/0.i cannot checkout and update this file. Cannot delete the branch with 0 version also. I am stuck . – user2636464 Dec 30 '17 at 06:53
  • 1
    This is at least more information about BDTM than I have found anywhere else on the net. +1. I have deleted my answer: it was just noise compared to yours. – VonC Dec 30 '17 at 08:39
  • this is an xml file. why you are asking to open using gzip? sorry I am not able to understand this point – user2636464 Dec 30 '17 at 16:29
  • ClearCase stores element versions in at least 4 different ways, depending on the file contents. In order to diagnose and resolve the issue, you need to look at the underlying storage, where the problem actually resides. BDTM's INTERNAL storage architecture, as opposed to the user visible storage, stores the version data as described above. My recommendation about opening a PMR is a "very strong" recommendation as I have seen "creeping corruption" caused by overly aggressive security policies (particularly Date Leak/Loss prevention software packages). – Brian Cowan Dec 31 '17 at 16:07