Running Clearcase 7.1.1.09 on a windows server. Lost+found directory element was removed using CCRC from a VOB. I can still see the lost+found directory in main/0. How can I restore the lost+found directory element of a VOB? According to this article http://www-01.ibm.com/support/docview.wss?uid=swg21135672 the lost+found directory element cannot be removed whatever that means.
Thanks for any help.
It means the /Vobs/MyVob/main/0 will always contain lost+found.
You may have ln, renamed or moved lost+found in more recent version of that Vob (like, for instance /Vobs/MyVob/main/4), you can always:
cleartool co -nc /Vobs/MyVob
cleartool ln /Vobs/MyVob/main/0/lost+found /Vobs/MyVob/lost+found
cleartool ci -c "restore lost+found" /vobs/MyVob
In Windows:
cleartool startview aDynamicView
cleartool mount \MyVob
cd m:\aDynamicView\MyVob
cleartool co -nc .
cleartool ln .##/main/0/lost+found ./lost+found
cleartool ci -c "restore lost+found" .
That would create, in this example, a 5th version of the Vob root directory, with in it referenced once again the lost+found directory, effectively restoring it.
(as shown in this thread, see also cleartool man ls)
Since ln isn't available a sa CCRC command, you need to contact a ClearCase admin who will have access to the CCRC server (and the full ClearCase vob server) in order to restore that lost+found directory.
Related
How can I obtain the list of changed files, given that I have an activity name (and also a project and stream name)?
This is what I tried:
cleartool lsact -l someActivity
But it returns:
cleartool: Error: Unable to determine VOB for pathname ".".
I suppose I should be in the correct view in order to get the contents. Is it also possible to retrieve all content without being in a view?
I obtained someActivity with an cleartool lsproj, then an cleartool lsstream -s -in someProject and then cleartool lsact -in someStream. I can do all these cleartool invocations without being in a view, so I'd like to obtain the changeset.
I'm found this question but the answer only works when in a view. For the record, I'm not confusing the ID with the headline.
You would at least need to add the pvob in which that activity was created:
cleartool lsact -l someActivity#/vobs/aPVob # Unix
cleartool lsact -l someActivity#\aPVob # Windows
cleartool lsact can use the current view if you don't specify any pvob:
If you specify a simple name and the current directory is not a project VOB, this command assumes that the activity resides in the project VOB associated with the stream attached to the current view.
If the current directory is a project VOB, that project VOB is the context for identifying the activity.
lsact would also need a view if you want ClearCase to resolve the path of each version (resolved using the current view path).
Otherwise it would list extended pathnames for each version.
I stopped and started a view for which various file access actions were hanging (after killing all my terminal sessions where I was using that view), and now get:
cleartool: Error: Operation "view_ws_is_ws_view" failed: view storage directory or control files unavailable --
additional information may be present in the view server host's view log.
Two questions:
1) Is there a clearcase subsystem that can be restarted to fix this (preferably without impacting other users)?
2) the very unhelpful error message refers to a view log, but doesn't say where it is. Where can this log be found (SUSE Linux Enterprise Server 11 SP3 (x86_64))?
clearcase subsystem that can be restarted to fix this
You can start by ending the view_server.exe associated to this view (cleartool endview):
cleartool endview -server <view_tag>
Then:
cleartool startview <view_tag>
Where can this log be found
This would use the cleartool getlog command, for local logs, but also for logs from the ClearCase view server (accessible from your client workstation)
cleartool getlog -tag <view_tag>
To display the last 10 lines of the view logs (logs for any view):
cleartool getlog -host <server_name> view
To display view log entries within 20 minutes of 4:00 P.M. on June 19:
cleartool getlog -host <server_name> -around 19-Jun.14:00 20 view
See also (in addition of the above recommendations) the IBM technote swg21131145 or technote swg21131682.
If above isn't enough, I like to fix_prot the view in order to avoid any right access issue.
If your view is on Unix, for instance:
alias sfp sudo /usr/atria/etc/utils/fix_prot
sfp -force -rec -chown <user> -chgrp <group> -chmod 775 /path/to/views/storage/<view_tag>.vws
sfp -force -root -chown <user> -chgrp <group> /path/to/views/storage/<view_tag>.vws
I have having an issue in clearcase delivery. There are some files that are checked out from a snapshot view and the view has been removed. I am trying to deliver from a dynamic view in unix. Since I can see those files checked out in the activity, is there a way to check in those files and proceed the delivery operation?
You can simply remove completely the view: that will cancel the checkout state of those files, and will allow you to resume the deliver.
See "ClearCase: Is it possible to cancel checkouts not made from your own view?".
cleartool rmview -force -uuid (uuid_of_the_view) -vob \aVob
You can find the uuid of the view by doing a cleartool descr -l vob:\aVob.
For snapshot views, you can regenerate the .view.dat and unco the file that way, with "Uncheckout an element from a snapshot view when the view root directory is not accessible"
List the checkouts to identify the view and checkout information
Create a new temporary view root directory
Regenerate the view root to the new temporary directory
ccperl "C:\Program Files\Rational\ClearCase\etc\utils\regen_view_dot_dat.pl\" -tag <view-tag> <tmp-dir>
Cancel the checkout
cleartool unco -rm <tmp-dir>\<vob>\<path>\<checkedout-file>
Remove the temporary directory
rmdir /S/Q <tmp-dir>
On Unix in a dynamic view, I run the following to find checked out files:
cleartool lsco -s -cview -me -avobs
In a windows snapshot view, this use of -avobs doesn't appear to work. On a vob by vob basis I can run:
cleartool lsco -s -cview -me -all
which returns the checked out names to me for that vob.
Is there a way to tell what vobs have checkouts in a Windows snapshot view? (not sure if Windows vs. Unix is a factor here). I'd like to script the lsco, executing it in each of the vobs in question.
Considering each vobs is a direct child directory of the root directory of your snapshot view, all you need to do is to:
list every direct child directory (whose name represents a vob)
execute your cleartool lsco within each of those directories.
This is consistent with the issue around the usage of "-cview -avobs" mention in this technote:
Local fix
Do not use lsco -cview -avobs.
You needs to run cleartool lsco while cd'd in each Unix vob in the Windows snapshot view.
I am having a doubt in creating an admin vob.
Can anybody give an example in commandline? It is urgent.
update: thanks vonc for giving me the answer but i am using base clearcase and when i am creating tag to adminpvob its not treating as adminvob. Can you please explain me in detail with an example.
If you are using UCM, you need to create an Admin PVob in order for all UCM components to see each others.
If you are using base ClearCase, a simple Vob is enough (remove the '-ucm' option)
For instance, on a Unix ClearCase server:
$sudo /usr/bin/atria/bin/cleartool mkvob -tag /vobs/adminpvob -c "Global Admin UCM pvob" -ucm -public -password clearcase -host MY_SERVER -hpath /MY_SERVER/vobstore/adminpvob.vbs -gpath /net/MY_SERVER/vobstore/adminpvob.vbs /net/MY_SERVER/vobstore/adminpvob.vbs
Note: you need to declare the admin(p)vob tag in every ClearCase regions you are using.
Fort instance, on Windows:
ct mktag -vob -tag \adminpvob -public -password clearcase -host MY_SERVER -gpath \\MY_SERVER\vobstore\adminpvob.vbs \\MY_SERVER\vobstore\adminpvob.vbs
Once you have created a UCM PVob for instance, you can link it to your admin VOB:
ct mkhlink -c "Link to my pvob" AdminVOB vob:\mypvob vob:\adminpvob
Created hyperlink "AdminPVOB#107#\mypvob".
Note: you can chain several Admin Vobs, but I would recommend an Admin PVob as the main one (with all the other linked to it). That way, even if you are not using UCM right now, any PVob you might create later can then just be linked to that global AdminPVob.
Simple Vobs can also be linked to it, enable ClearCase to share tag and branch names accross base ClearCase Vobs.
If you are Base ClearCase only:
$sudo /usr/bin/atria/bin/cleartool mkvob -tag /vobs/adminpvob -c "Global Admin vob" -public -password clearcase -host MY_SERVER -hpath /MY_SERVER/vobstore/adminvob.vbs -gpath /net/MY_SERVER/vobstore/adminvob.vbs /net/MY_SERVER/vobstore/adminvob.vbs
ct mkhlink -aquire -c "Link to my pvob" AdminVOB vob:\mypvob vob:\adminvob
Created hyperlink "AdminPVOB#107#\mypvob".
Note the '-acquire`' option, as specified in this IBM article.
To avoid eclipsed types, you should create the AdminVOB hyperlink with the -acquire option.
You have the full process in the help manual here.
An administrative VOB hierarchy includes at least one administrative VOB and one or more VOBs that have an AdminVOB hyperlink to it or to another VOB that has an AdminVOB hyperlink to it.