For some reason some users produced some files that end in "##" (...) (I think because they have in the CCRC the gui option to show the version extended pathname and i think that has somewhere a little bug).
Now... they are unable to remove or rename these files (it returns "not a object in the vob")
how can they rename or remove these files?
update
Resolved I forgot to use the complete rmname "a.doc####\bla\1", after the full path i could delete them.
The simplest solution would be to try to list and remove those objects from a base ClearCase view directly on the CCRC server (or any base ClearCase client).
From this kind of ClearCase installation (CCRC server or full ClearCase client), you do have access to cleartool (the ClearCase CLI -- Command Line Interface --), and you can:
cleartool ls: list the files in the view, to check those files with ## are indeed there
cleartool rmane -force to remove them
The OP used
cleartool rmname "a.doc####\bla\1"
, meaning he had to use the extended path (file name + ## + version path) of the file ended with ##, hence the four #: file####version.
Related
In the clear case, I want versions of the file in the particular directory with complete file path. By right click on the file and after that going for properties in the file it is possible to take, but in case in the directory 100 files are there, so it will become very huge task. I want to know the clear tool command , which i can execute from the command prompt and after that I can redirect output to some text file
Example of path I am using:
M:\My_Project\Verif_Folder\TP\Functional_TP\ETP\ here
Check the command cleartool find, combined with a cleartool describe and fmt_ccase option:
cd M:\Myproject\...\here
cleartool find . -type f -exec "cleartool describe \"%CLEARCASE_XPN%\" -fmt \"%Xn\""
%Xn: Extended name: Same as default
%n output, but for checked-out versions, append the extension ##\branch-pathname\CHECKEDOUT
The result will be the path of the file, its name, and its extended path including its current selected version.
I have a view, for some reason, it was named with a special character: "0x7f", at least I think so..
For example:
MyView123456 -> MyView'0x7f'123456
I can only found this view by
ct lsview #list all views.
And I found this "0x7f" when dump the outputs to a file.
And using vim.
Now I'm trying to delete this view totally.
I can unregistered and delete the view itself by -uuid.
But I cannot delete the view tag.
And I also found wildcard '*' seems not working.
Does anyone know how to delete this view tag?
P.s. I'm under Linux, and no GUI.
Try first if dome of the workaround described in "Removing ClearCase objects whose name begins with a hyphen", when using cleartool rmtag:
cleartool rmtag -- MyView*
Note the use of '--' in order to separate the command from its parameters
The wildcard being expanded by your shell, try and use it instead in the cleartool interractive session:
cleartool
> rmtag -- MyView*
In Linux shell, see if a single quote is enough:
cleartool rmtag -- MyView'0x7f'123456
# or
cleartool rmtag -- 'MyView0x7f123456'
I was able to create and remove a view with binary data in the tag using Perl. You have to use the OCTAL value of 177 in the strings.
I created my view using this command line:
perl -e '`cleartool mkview -tag myview\177tag /net/bullwinkle/export/vobstg/binarytag.vws`'
And I successfully removed that view tag using this command line:
perl -e '`cleartool rmview -tag myview\177tag`'
If the view was unique enough, you could also use (on Unix) or at least try:
cleartool rmview -tag `cleartool lsview 'myview*123456'`
There is another mechanism, if all else fails: you can edit the vob_tag registry file. This would require an outage as the registry file is loaded into the registry server's memory on clearcase startup and only re/written after that point.
The process is:
Stop ClearCase on the registry server
CD to /var/adm/rational/clearcase/rgy (Unix) or {CC Install dir}\var\rgy (Windows)
Back up the vob_tag file.
load the vob_tag file in an editor. (vi/gedit on unix, but I'd use notepad++ on windows)
locate the problem view tag (you may need to search on the global path or some other component of the name).
Make note of the path to the view.
Delete the line.
Start ClearCase on the registry server
unregister the view or retag it with an easier-to-access tag.
Presently I follow this process:
Right click the root of the project and click on Find Modified Files.
Then in the ClearCase Snapshot View Update window, the modified (hijacked) files are shown.
By right click on the file name and click on Compare with Old Version, difference between local hijacked file and the server copy are displayed.
However, the above approach takes very long time (as step 1 itself takes 10 minutes). If I already know the hijacked file path, then is there a faster way to do the same?
This 2007 thread summarizes the options you have; the command line with cleartool 9.0.1.3 also offers a diff, even though the thread claims that it doesn't. See bottom of the post.
convert the hijack to checked out (then you can diff)
OR
rename the hijacked file to something else (like filename.hijacked), reload filename (cleartool update filname) update the file, then run cleartool diff filename filename.hijacked.
OR
run the diff against the dynamic view version (from command-prompt, cd to the hijacked file location, then do the cleartool diff filename M:\view\VOB\path\to\file)
I used to do the third option, as it does not require to touch the hijacked file.
With cleartool, compare an extended path name specifying a version, e.g. /main/LATEST, to an simple path. (A command line can be opened conveniently from the context menu of a folder in ClearCase Explorer.)
cleartool diff file.c##/main/LATEST file.c
I am trying to delete a file in ClearCase. When I attempt to delete it I get a message that the element has checkouts. When I do a version tree on the file I see that the file is checked out by another user, in another view, on a different branch.
How do I delete this file? In addition why doesn't ClearCase let me delete this file?
You can delete it through the command line and cleartool, by forcing its delete (option which isn't available with the GUI)
cleartool rmname -force theFile
Don't forget to checkout the parent directory first, then to checkin that same parent directory, in order for everyone to see that you have dereferenced that file within said directory.
See cleartool rmname:
–f/orce:
Forces the removal of the name when there is at least one checkout of the element.
When used with –nco, suppresses the prompt for confirmation.
That will work even when you had this before:
, as explained in the technote "About cleartool rmname and checkouts".
Given a file system path such as "D:\pkirkham_view\VOB\Folder" or "U:\VOB\Folder\", is there a mechanism to get the path which would work in the config-spec to to load that folder "/VOB/Folder/" ?
Either CAL or cleartool commands would be fine. This is to run on client machines with ClearCase LT installed.
(I haven't found anything usable in CCElement.get_PathInView() or the various cleartool ls commands I've tried)
There is no native command, but the only load rule you need is based on a vob name.
So you need a script able to:
1/ remove everything including the name of the view
(which you can obtain with a '<aPathTo>\VOB\Folder\;cleartool cleartool lsview -s -cview)
D:\pkirkham_view\VOB\Folder => \VOB\Folder
U:\VOB\Folder\ => \VOB\Folder
2/ Build your load rule accordingly:
load \VOB\Folder
3/ Append that load rule to your config spec (if you are already within the view):
cleartool catcs > aConfisgpec.txt
echo "load \VOB\Folder" >> aConfisgpec.txt
cleartool setcs aConfisgpec.txt
The OP comments:
So, if I create a snapshot view whose tag name is 'pkirkham_testing_view' on path 'D:\thursday', how is that a substring extract?
That is a good point, since one can name the root directory with any name.
I would recommend naming that directory with the tag of the view.
But that is not the case, you need to determine the root directory of a snapshot view:
start in 'D:\whatever\path\VOB\Folder',
try a cleartool lsview -cview:
if it respond correctly, cd .., and repeat 2.
When it exit with an error, remove the substring of that directory from the initial path. What remains will be your load rule.