I am attempting to create a relative symbolic link via clearcase as so:
ct ln ../../../some/actual/file.txt file.txt
However, I get the following error:
cleartool: Error: Source "../../../some/actual/file.txt" and destination "file.txt" are in different versioned object bases.
In context of clearcase relative symbolic links, what does "different versioned object bases" mean?
First "in different versioned object bases" refers to VOBs, two different permanent data repositories in which you store files, directories, and metadata.
A cleartool ln without the -slink option would create a hardlink, that is an additional name for an existing element.
And:
For VOB hard links, each pname must specify an existing element that is not a VOB symbolic link and that resides in the same VOB as the link being created.
For VOB symbolic links, pname need not reside in the same VOB as the link to it, nor be an existing element.
Related
How to search all archived file that exceeds 100MB in a particular BASE Clearcase VOB. In Unix file system, it is easy:
find . -type f -size +104857600c -exec ls -la {} \;
Would it be possible to search directly in the folder of the VOB in the file system without create a Clearcase view and modify the config spec?
If I have to create a Clearcase view, would it be possible to use the cleartool command find to search in the whole VOB.
As mentioned in this technote:
At present there is no size option available with the cleartool find command.
The decision was made by Product Management to exclude the requested feature from future upgrades and releases due to the significant architectural changes required to implement the solution.
So creating a view remains mandatory.
And you can either directly use the ClearCase Explorer:
Or use your regular Linux command in a dynamic view:
# find . -size +20480c -print
./vendor/Common/NT/work/toolset/make/cal.output
./vendor/Common/NT/work/toolset/make/paf.output
would it be possible to use the cleartool command find to search in the whole VOB.
"The whole VOB" as in "all possible versions"... not really, unless you try and find files in the extended pathnames of an MVFS dynamic view. I haven't tested that option so.
I am not been able to mount vobs in windows region but I have been able to access the vob storage location through windows explorer.
When I run cleartool mount -all, it generates the following error:
cleartool error: the vob storage directory \\..\... is not found.
When I try to start dynamic view, it generates:
cleartool: Error: Could not register gpath in the prefix map
Do you have any suggestion?
As mention in this thread:
The "prefix map" referenced here means a UNC path. This error means
that for some reason, your NFS client was unable to create a valid UNC
path for ClearCase to traverse. Check if your NFS client is working
properly, and if the UNC path is valid (eg readable at the least)
One potential solution (which may or may not apply to your environment) is for a mixed interop environment where all the VOBs and dynamic views are located on two Linux servers and SAMBA is used for sharing the storage areas from Linux to Windows CC clients.
Start->Settings->Control Panel->Clearcase->
Options Tab->
Uncheck "Enable automatic mounting of NFS storage directories"->
Apply->Ok
This thread also mentions:
I've seen similar before. The cause of our problem was incorrect access permissions to our UNC path equivalent of \\piglet\viewdata\pete_te_31.1.vws.
From explorer, try to map a drive to piglet's share, viewdata.
An alternative to that is a result of a different but not wholly dissimilar problem we had concerning NT (4.0 sp 4) client resident views accessing UNIX (Solaris 2.6) resident VOBs. We use DiskAccess to achieve this. The problem read as follows:
Occasionaly, on clients with existing mappings to VOB storage they would be
presented with the error message:
mvfs: ERROR: view=fi65115_fesco vob=\fesco_orion - ClearCase vob
error see view_log on host blah blah.
Or alternatively for clients without existing mappings to VOB storage making new mappings, would simply see an empty drive i.e. L:\ (UNC equiv equals \\fiscdub002\vobstorage).
We found that we had to manually 'reshare' vobstorage with the following (as root) from our Solaris 2.6 VOB server:
share -F nfs -o rw /dub2box1 (where /dub2box1 is vobstorage).
So to recap, check the permissions to the share and verify that the share has 'contents' (for want of a better way of putting it).
I need to move multiple symlinks within a VOB in a dynamic view.
As described in my previous question, this is not as trivial as it sounds (to me), as the target path is saved relative to the link itself and not to the VOB root or anything like that. This wouldn't be a big issue, if ClearCase would adjust the path information in those links, but appearantly, it does not.
Details: Let's assume following folder structure:
/myVOB
/Originals
/LinksA
/SubDir
/LinksB
Then moving a link to the file myVOB/Originals/readme.txt that is located in myVOB/LinksB to myVOB/LinksA/SubDir will prevent the link to find its target, as it is looking for myVOB/LinksA/SubDir/../Originals/readme.txt.
Does anyone know if it is possible to tell ClearCase to adjust the paths when moving symlinks? Usually I would think this should be done out of the box, but one never knows with ClearCase... Nevertheless, perhaps someone could try to reproduce this and tell me if it succeeded or not, perhaps it's just a bug on my system?
Edit: OK, so it looks like moving relative symlinks is not supported out-of-the-box. Would I need to move a great number of symlinks, I'd be writing a script right now that took a number of files/directories and moved them to a new location. If it encountered a symlink (whose target may be a file or directory) it would not just call cleartool mv or whatever, but follow the procedure as posted by VonC.
But I don't, so I'll probably do this by hand. Perhaps someone already wrote such a script, then this would be the right place to promote it ;)
If you consider this technote on "How to Manage symbolic links in ClearCase interop, it seems that:
(even if you aren't in an interop environment, ie even if your Windows views and Vob server are both on Windows)
symlinks are using primary relative path
you must recreate them if the target path change.
How to change a VOB symbolic link path
The only way to revise a VOB symbolic link to a relative path is to create a new symbolic link:
Note: You cannot edit (revise) a VOB symbolic link if it has been created using an absolute path to utilize a relative path.
-Check out the directory
- Remove the old VOB link using the cleartool rmelem command
- Create a new link with the same name
Example:
cleartool ln -slink -nc ../../same_file_name.txt
Check in the directory
Notes:
It is recommended that you use relative VOB symbolic links instead of absolute symbolic links.
The absolute VOB symbolic link requires you to use absolute path names from the view-tag level, for example, \view-tag\VOB-tag\filename.
Hence, they are valid only in the view in which they were created.
I'm trying to change the ownership on a VOB, and I see that the cleartool protect command has a chown option. It's asking for a pname, and I can't seem to find documentation on what a pname is or how to specify one. I guess my questions boil down to:
What's a pname? What's its format?
How do I specify the pname for a VOB?
Is there documentation on pnames somewhere? Or at least examples of changing ownership of VOBs.
Changing the ownership of a Vob is done through cleartool protectvob.
It will require the "pname-in-vob":
The pathname of the VOB tag (whether or not the VOB is mounted) or of any file system object within the VOB (if the VOB is mounted).
I.e: /vobs/MyVob (unix-style) or \MyVob (usual Windows declaration for Vob tags)
It is different from cleartool protect, which would only protect an element (file or directory), which is, in the case of a Vob, the root directory of the Vob.
The path of that root directory would be the pname.
But again, that wouldn't change the ownership of the Vob.
"pname" is a VOB path name. An example element path name would be M:\view1\vob3\src\main.c or /vob3/src/main.c (depending on your platform). cleartool protect changes permissions or ownership of a VOB object identified by its pathname
Why do I get these .MKELEM files? How do I get rid of them?
I found some docs that said they are temp files created by ClearCase GUI when adding files to source control. But sometimes, they don't go away.
ADDITIONAL INFORMATION: I "get access denied" trying to delete or rename the .MKELEM. They seem to get created when I add new files to clearcase.
As mentioned in the mkelem tip page:
During the element-creation process, the view-private file is renamed to prevent a name collision that would affect other Rational® ClearCase® tools (for example, triggers on the mkelem operation). If this renaming fails, you see a warning message.
If a new element is checked out, mkelem temporarily renames the view-private file, using a .mkelem (or possibly, .mkelem.n) suffix. After the new element is created and checked out, mkelem restores the original name. This action produces the intended effect: the data formerly in a view-private file is now accessible through an element with the same name.
If mkelem does not complete correctly, your view-private file may be left under the .mkelem file name
The fact that a .mkelem stays can be, like LeopardSkinPillBoxHat mentions in his answer, because of a file blocked due to a process.
It can also happens:
in ClearCase view incorrectly protected (where ClearCase can checkout the new element, creating a version 0, but cannot check that element in.
alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/topic/com.ibm.rational.clearcase.dev.doc/topics/cc_dev/images/creating_element.gif
when a trigger prevents the checkin part of the new element creation
when the view actually exclude CHECKEDOUT versions! (no 'element * CHECKEDOUT' rule...)
on Solaris 10, due to an incorrect format in one of the ClearCase jvm config file. (ClearCase 7.1)
when add to source control is used on Windows in views mapped to a mount point (Mount points are persistent directories that point to disk volumes), only in old ClearCase 2002 or 2003.
See also the Under the hood: What happens when you add to source control article.
The .mkelem files are temporary files generated by ClearCase when adding a file to source control. If the file gets added succesfully, they are usually deleted. If something goes wrong during the process (e.g. it cannot create the branch specified in your config spec), the .mkelem file may be left behind.
I'm guessing that a process or service somewhere has a lock on the file. Rebooting should fix the problem. Or try using something like Process Explorer to see what may have locked the file.
Also, from this page:
.mkelem
Files being added to source control
from the GUI will use this extension
during an "Add to Source Control"
operation.
If you see this file in your view
during the mkelem process, that is OK.
If you still see the file after the
mkelem operation is complete, that is
not ok. You will likely need to rename
the file (remove the .mkelem
extension) and add it to source
control again. This can be seen when
your antivirus software is scanning
the mvfs. Refer to technote 1149511
Support Policy for Anti-Virus and
ClearCase for further information.
You may try the following from command prompt:
ct ls -l {filename}.mkelem
This will show the links,
then please try the following to link the actual file:
ct ln -c "scm:relink" {link} {actual filename}