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
Related
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.
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 cannot see pvob on clearcase GUI but when I list the vobs in command line (cleartool lsvob -s), I can see it.
In order to make it visible on the clearcase GUI, what are the necessary steps should I take?
Also it looks like a private Pvob, how can I make it public?
The Pvobs are visible in the ClearCase Project Explorer (type clearprojexp), not in the ClearCase Explorer ('clearexplorer').
The pvob could be used as a vob, but it normally is used only as a referential for UCM metadata (projects, streams, activities...), and not for data (files/directories).
It is an Admin vob for other (data) vobs, which explains why you don't see it in the ClearCase explorer.
For your second question, you need to use the cleartool mkvob command:
UNIX, Linux, and Windows: Private-to-public VOB conversion
To convert a private VOB to a public VOB, use a command like this:
cleartool mktag -vob -tag \vob3.p -replace -public \\saturn\users\vbstore\private3.vbs
This replaces the VOB's private VOB tag with a public one.
mktag prompts you to enter the VOB tag password.
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.