"Access Denied" error trying to delete a ClearCase .mkelem file.

Question

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.

Answer 1

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.

Answer 2

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.

• 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.