Here is the situation,
I have installed and configured ClearCase Multisite,I did a mkreplica from SITEA (/dev) to SITEB (/dev). My import went successfully on SITEB. I happen to do few syncreplicas too on Both( SITEA and SITEB). I had both configured on Win2003.
Now the SITEB Operation system Win2003 happen with some OS related issues. Now I had recreate an Instance of win2003 and configured CC Multisite on it. Now since everything had been wiped out: I tried to do an mkreplica from SITEA /dev to SITEB /dev (A win2003 new instance)
But, to my surprise, it says SITEA has already exported a packed and exits.
I wanted to know if there is a way to wipe out old history of SITEA for /dev or do I have to rename SITEB to something different? I haven't tried renaming but before I do just need some views over it.
Amit
I no longer work in a clearcase environment, so this is from memory, but in order to get an exact overview of what is exported or not run the
multitool lsepoch
command and then try to figure out which epoch numbers that are not up to date (as far as I remember you can request numbers from the remote side with the -actual option). If you want SITEA to re-export some things it thinks it already is finished exporting, you have to change the epoch number for the replica you want to import into.
When you consider the mkreplica man page, it could be as simple as the destination directory (the directory for use by mkreplica as a temporary workspace) already existing.
You also have this technote which reports why the error, multitool: Error: Unable to create directory ".../VOB.vbs/s": File exists, occurs when attempting to import an IBM® Rational® ClearCase MultiSite® replica creation packet using multitool mkreplica -import.
It involves unregistering (unregister+rmtag) the vob created by the first mkreplica.
if you are 100% certain that SITEA is most up to date, and the old SITEB is no longer needed. You can do this...
At SITEA
cleartool chmaster -all -obsolete_replica replica:SITEB replica:SITEA
cleartool rmreplica replica:SITEB
Once the above is done, you are free to re-create SITEB from SITEA as per your usual practice.
Related
I have a Linux subsystem installed on my Windows machine. I've transferred a tar.gz file I want to access by finding the location of my subsystem and dragging the files over. But when I run the command:
tar -zxvf file_name.tar.gz
I get the error:
tar (child): vmd-1.9.4a51.bin.LINUXAMD64-CUDA102-OptiX650-OSPRay185.opengl.tar.gz: Cannot open: Permission denied
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
I assume permission being denied is to do with having transferred from Windows since I couldn't access directories I created through Windows either. So, is there something I need to change to gain access to these files?
(PS. I know there are other way of getting tar.gz files other than transferring from Windows, but I'll need to do this for other folders too, I only included the filetype in case it was relevant .)
EDIT: You shouldn't attempt to drag files over. See answer below.
For starters, this belongs on Super User since it doesn't deal directly with a programming question. But since you've already provide an answer here that may be slightly dangerous (and even in your question), I didn't want to leave this unanswered for other people to find inadvertently.
If you used the first method in that link, you are using a WSL1 instance, not WSL2. Only WSL1 made the filesystem available in that way. And it's a really, really bad idea:
There is one hard-and-fast rule when it comes to WSL on Windows:
DO NOT, under ANY circumstances, access, create, and/or modify Linux files inside of your %LOCALAPPDATA% folder using Windows apps, tools, scripts, consoles, etc.
Opening files using some Windows tools may read-lock the opened files and/or folders, preventing updates to file contents and/or metadata, essentially resulting in corrupted files/folders.
I'm guessing you probably went through the install process for WSL2, but you installed your distribution before setting wsl --set-default-version 2 or something like that.
As you can see in the Microsoft link above, there's now a safe method for transferring and editing files between Windows and WSL - the \\wsl$\ tmpfs mounts. Note that as a tmpfs mount stored in memory, it's really more for transferring files over. They will disappear when you reboot or shutdown WSL.
But even if you'd used the second method in that article (/mnt/c), you probably would have run into permissions issues. If you do, the solution should be to remount the C: drive with your uid/gid as I describe here.
Once you label file versions in a release, ideally you want to protect that code from inadvertant removal (please read everything before commenting). It is too easy to delete the code.
I know I can lock the label but the file versions attached to the label don't get automatically locked (you would have to create a perl script to do that?). You can lock an element but not an element version. Furthermore, once you lock an element, you can't check it out!!!!! STUPID. This stops future development! All I want to do is protect the code I developed (without copying it elsewhere for archive). A repository should protect the code you develop.
Of course, there is the protect command but that doesn't work in snapshot / web views.
Again, ideally you would want to lock all the element-versions in a release but still be able to continue development. The lack of this feature seems to be a gross oversight.
Any ideas? (if you have any perl scripts, please post)
It is too easy to delete the code.
It shouldn't be: the only way you will be removing that labelled version from a ClearCase VOB is through destructive commands like cleartool rmelem or cleartool rmver.
All you need to do is to have a (preop) trigger in place denying those commands for everybody (except a ClearCase admin).
Something along the lines of:
cleartool mktrtype -nc -all -ele -pre rmelem -nusers $nusers -exec \"$perl_cmd -e exit(1)\" NO_RMELEM\aim"
I would still recommend to lock the label anyway, in order to make sure it isn't moved to another version.
As in:
ct lock -nusers vobadm lbtype:FOO_LABEL#vob:/vobs/admin
But again, if rmver is denied, your (labelled) code is safe.
Actually, the OP was talking about rmname (the DEL) in ClearCase Explorer.
The fear is that if a file is deleted, and a label is moved, then one could ignore for a long time the deletion.
BUT a label should never be moved:
the label from a ClearCase UCM baseline is immutable (you cannot move it)
a label in base ClearCase should always be locked
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".
In the process of symlinking my dotfiles (.vimrc, .zshrc, .bashrc etc.) I wrote a simple ruby script to do this for me so I could switch between two different sets of dotfiles... however in the process I made a dumb mistake, and ended up linking my backup files as symlinks of the home folder copies, and vice versa... making them not accessible (vi says permission denied)
So I tried unlinking the backups, and now the files read 'no such file or directory' in my home folder, yet 'locate .zshrc' tells me its there. I realize it would have been prudent to push them to a repo first. Any suggestions?
locate works off of a cached database; you'll have to updatedb (possibly with root) in order to update said database.Unfortunately, that means said files are probably gone forever.
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}