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.
Related
I'm having a tough time with ClearCase. I'm working with a dynamic view.
Somehow, I got two files that are eclipsed. I compared the folder in my version (with the eclipsed files) with every version on my branch and every version on the main branch. The original files are nowhere to be found.
I searched for the files in Windows Explorer and found them in the lost+found directory (with a 32 character extension). This directory appears to be invisible because I can't see it in either Windows Explorer or ClearCase.
I opened a DOS window and ran cleartool. I removed the files (I had fun typing it all, plus the 32 character extension at the DOS prompt). I could not find a way to delete them from either Clearcase Home Base or ClearCase Explorer.
I thought this would solve my problem, since there are no more files with the same names anywhere on my computer.
I deleted the eclipsed files and created them again in Qt Creator. But when I opened ClearCase Explorer again, there they were - eclipsed! I cannot figure out where the evil twins are. I tried finding the eclipsed files by using cleartool. Nothing. I've tried many approaches I've found online - none work.
I tried stopping and starting the view. I deleted the eclipsed files again, closed Qt Creator and then opened Qt Creator again and recreated them. I tried many other things suggested - none made any difference.
If I'm eclipsing existing files, where are they? I'm starting to think that the real evil one here is the parent - ClearCase!
Eclipsed doesn't mean evil twins (the fact that you add multiple times a file does though).
When you add to source control a file, ClearCase will:
checkout the parent directory
access the file in order to create a temporary one (called 'afile.mkelem')
create the file in the ClearCase vob
check in the parent directory
I usually see repeated eclipsed file when ClearCase isn't able to access the content of a file, because another process prevents it.
Try adding those files after closing the Qt editor.
The OP Rob Moore mentions having solved the issue with:
I changed the view to main/LATEST, and the file showed up.
I went to the tree view of that file and noticed that I had a branch there with one version.
I compared my branch version with the main/LATEST and they were the same, so I deleted my branch and put my label on the main/LATEST version
So it is possible that, as soon as the element was added, it wasn't properly selected by the config spec (being a new version on a branch which wasn't part of the config spec), and its state reverted to "eclipsed".
what is symbolic link in solr. Is there any concept exist in solr related to schema..?
Is it related creation of class object specified in schema.xml.. ?
Symbolic link is a concept in computing not in Solr.
In computing, a symbolic link (also symlink or soft link) is a special
type of file that contains a reference to another file or directory in
the form of an absolute or relative path and that affects pathname
resolution.
One of the exaple when you need symbolic link is, if you install solr using package manager then it installs default configuration files (schema.xml , solrconfig.xml). So, you need to replace this default configurations with yours by creating a symbolic link.
Check this post, it could give you an idea.
I am having a folder where lot of files and subfolders , adding it to source control via UI is consuming much time.
How to add all the files (including files inside subfolder) to source control using cleartool?
(I am using clearcase UCM)
As mentioned in "How can I use ClearCase to “add to source control …” recursively?", clearfsimport is the way to go.
However, clearfsimport will take a source an import it in your view, so:
it is best to keep the source outside your view (to avoid confusion when ClearCase tries to add the source file in the destination which is the same directory)
you must "clean out" the source directories first (because the clearfsimport command will import... all the files under the root directory you mention)
See "Creating a new subdirectory structure in ClearCase?" as an example: you can preview the result of an import first.
Please user clearfsimport or if you are working with eclipse or Intellij then there are plugins from sourceforge (eclipse) which has a options to share entire project at once to CLearcase , Below are the plugin details.
https://sourceforge.net/projects/eclipse-ccase/
Note : Clearcase has a limitation that if there is a text file with more than 8000 characters in single line , There is error at run time using clearfimport utility, This can be solved by writing your own bash script to do recursive checkin by handling the exception case . Hope it helps .
I saw another comment from a similar clearcase question that suggested typing in '*' in the topmost directory required, select all, rc->cc->add to source control.
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}
I recently followed a small tutorial on howto install apache on a systems where you're not the admin. Basically, the original htdocs and conf folders were copied to a map I have ownership over, the original ones deleted and then symbolic links were created.
Now, I checked mklink /? and it gives several options.
Directory symbolic link
Hard Link
Directory junction
Microsoft technet doesn't offer much explanation as to what the last 2 options really do.
So I'm wondering if there's someone here who can tell me what these options do and perhaps give an example of a situation where this is really usefull.
See the documentation on MSDN on Hardlinks and Junctions. It says:
A hard link is the file system
representation of a file by which more
than one path references a single file
in the same volume.
And:
A junction (also called a soft link)
differs from a hard link in that the
storage objects it references are
separate directories, and a junction
can link directories located on
different local volumes on the same
computer. Otherwise, junctions operate
identically to hard links.