Creates a file or directory element


ClearCase (cleartool subcommand), Attache (command)


mkelem [ -elt·ype element-type-name ] [ -nco | -ci [ -pti·me ] ] [ -master ] [ -nwa·rn ]

[ -c·omment comment | -cfi·le comment-file-pname |-cq·uery | -cqe·ach | -nc·omment ]
element-pname ...


The mkelem command creates one or more new elements. A new element can be created in a directory only if that directory is checked out. mkelem appends an appropriate line to the directory's checkout comment.

In Attache, any corresponding local files are uploaded before the command is executed remotely. Wildcards are expanded locally by searching in the workspace, rather than remotely.

mkelem processes each element as follows:

  1. Determines an element type from the specified -eltype option or by performing file-typing (see File Types and Element Types)
  2. Creates an element object with that element type in the appropriate VOB database
  3. Initializes the element's version tree by creating a single branch (named main), and a single, empty version (version 0) on that branch
  4. Does one of the following:
    • By default, checks out the element to your view.

    NOTE: At this point, other views see an empty file when they look at the element.

    • With the -nco option, does nothing.
    • With the -ci option, creates version 1 by copying a view-private file or an uploaded view-private file.

      In Attache, if elements are checked out, the corresponding files are downloaded to your workspace if they did not exist locally, or the local files are made writable.

  5. Assigns the element to the same source storage pool, cleartext storage pool, and (for new directory elements only) derived object storage pool as its parent directory element
  6. In a snapshot view, updates the newly created element

NOTE: Error messages appear if your config spec lacks a \main\LATEST rule. The mkelem command succeeds in creating version \main\0. However, because your view does not have a rule to select this version, you cannot see or check out the element.

The following sections provide more information on each of these steps.

File Types and Element Types

Each element is an instance of an element type (just as each version label is an instance of a label type, each attribute is an instance of an attribute type, and so on). You can specify an element type with the -eltype option. (The lstype -kind eltype command lists a VOB's element types.) The element type must already exist in the VOB in which you are creating the new element, or must exist in the Admin VOB hierarchy associated with the VOB in which you are creating the new element. A mkelem -eltype directory command is equivalent to a mkdir command.

If you do not specify an element type on the command line, mkelem determines one by using the magic files to perform file-typing. This involves matching patterns in the new element's name (and examining the existing view-private file with that name, if one exists; see the section Converting View-Private or Workspace Files to Elements). If file-typing fails, an error occurs and no element is created:

cleartool: Error: Can't pick element type from rules in ...

For more on file-typing, see the cc.magic reference page.

Access Mode

A file element's write access settings are essentially irrelevant; modifications to elements are controlled by ClearCase permissions, as described in the permissions reference page. When your view selects a checked-in version of a file element, all of its write permissions are turned off, corresponding to the fact that the element is read-only. When you check out an element, write permissions are added to the view-private copy. (See the checkout reference page for details.)

When you convert a view-private file to an element (see Converting View-Private or Workspace Files to Elements), it is changed to read-only. To add execute permission for an executable element, use protect -chmod +x (see the protect reference page) or the ClearCase Properties of Element dialog box.

Converting View-Private or Workspace Files to Elements

You can use the mkelem command to convert a view-private or workspace local file to a file element with the same name. There are several cases:

During the element-creation process, mkelem renames the view-private or uploaded view-private file to prevent a name collision that would affect other ClearCase or Attache software (for example, triggers on the mkelem operation). If this renaming fails, a warning message appears. There are two renaming procedures:

NOTE: If mkelem does not complete correctly, your view-private file or uploaded view-private file may be left under the .mkelem file name. In Attache, the file in your workspace is not renamed.

Converting Nonshareable Derived Objects to Elements

mkelem does not perform any special processing for a nonshareable DO. The process is the same as for a shareable DO, as described in Converting View-Private or Workspace Files to Elements. However, when you check in version 1 of the new element (with the -ci option or the checkin command), the command converts the nonshareable DO to a shareable DO, then checks it in. For more information, see Working with Derived Objects and Configuration Records in Building Software with ClearCase.

NOTE: When a nonshareable DO is converted to a shareable DO, its DO-ID changes. For more information, see Derived Objects and Configuration Records in Building Software with ClearCase.

Creating Directory Elements

To create a new directory element, use mkelem -eltype directory or mkdir. You cannot create a directory element with the same name as an existing view-private file or directory, and you cannot use mkelem to convert an existing view-private directory structure into directory and file elements. To accomplish this task, use the clearexport_ffile and clearimport utilities.

Auto-Make-Branch During Element Creation

If your config spec has a \main\LATEST rule with a -mkbranch clause, mkelem checks out a subbranch instead of the main branch. For example, suppose your view has this config spec when checked out:

element * CHECKEDOUT
element * ...\gopher_port\LATEST
element * V1.0.1 -mkbranch gopher_port
element * \main\LATEST -mkbranch gopher_port

In this case, a gopher_port branchis created a for the new element, and this branch is checked out instead of main:

cmd-context mkelem -c "new element for Gopher porting work" base.h
Created element "base.h" (type "text_file").
Created branch "gopher_port" from "base.h" version "\main\0".
Checked out "base.h" from version "\main\gopher_port\0".

The auto-make-branch facility is not invoked if you use the -nco option to suppress checkout of the new element. For more on this facility, see the checkout and config_spec reference pages.

Creating Elements in Replicated VOBs

By default, when you create an element in a replicated VOB, mkelem assigns mastership of the element's main branch to the VOB replica that masters the branch type main. If this replica is not your local replica, you cannot create versions on the main branch. (You can create versions on other branches if they are mastered by the local replica.)

To assign mastership of a new element's main branch to the local replica, use the -master option. The -master option also allows auto-make-branch during element creation, even if the branch type specified in your config spec is not mastered by the local replica. In this case, mkelem assigns mastership of newly created branches to the local replica. For example, suppose your view has the following config spec:

element * CHECKEDOUT
element * ...\gms_dev\LATEST
element * \main\LATEST -mkbranch gms_dev

When you create a new element with mkelem -master and do not use the -nco option, mkelem creates the branches main and gms_dev and assigns their mastership to the local replica.

NOTE: If you use the -nco option with -master, only the main branch is mastered by the local replica, because it is the only branch created by mkelem.

Referencing Element Objects and Their Versions

You sometimes need to distinguish an element itself from the particular version of the element that is selected by your view. In general:

For example, msg.c@@ references an element, whereas msg.c references a version of that element. In many contexts (for example, checkin and lsvtree), ClearCase allows you to ignore the distinction. But there are ambiguous contexts in which you need to be careful. For example, you can attach attributes and hyperlinks either to version objects or to element objects. Thus, these two commands are different:

cmd-context mkattr BugNum 403 msg.c (attaches attribute to version)

cmd-context mkattr BugNum 403 msg.c@@ (attaches attribute to element)

CAUTION: Do not create elements whose names end with the extended naming symbol. ClearCase and Attache cannot handle such elements.

Storage Pools

Physical storage for an element's versions (data containers) is allocated in the storage pools that mkelem assigns. You can change pool assignments with the chpool command.

(ClearCase only) Group Membership Restriction

Each VOB has a group list. You can create an element in a VOB only if your principal groupis on this list. See the protectvob reference page for more on this topic.


Permissions Checking: No special permissions required. Locks: An error occurs if any of the following objects are locked: VOB, element type, pool (nondirectory elements only).


SPECIFYING THE ELEMENT TYPE.  Default: mkelem performs file-typing to select an element type. If file-typing fails, an error occurs. See the cc.magic reference page for details on file-typing.

-elt·ype element-type-name

Specifies the type of element to be created. The element type must be a predefined type, or a user-defined type created with the mkeltype command. The element type must exist in each VOB in which you are creating a new element, or (if element-type-selector is a global type) in the Admin VOB hierarchy associated with each VOB. Specifying -eltype directory is equivalent to using the mkdir command.

CHECKOUT OF THE NEW ELEMENT.  Default: mkelem checks out the new element. If a view-private file already exists at that pathname, it becomes the checked-out version of the element. Otherwise, an empty view-private file is created and becomes the checked-out version. In Attache, if neither the -nco or -ci option is specified, the checked-out files are downloaded if they did not exist locally, or the local files are made writable.


Suppresses automatic checkout; mkelem creates the new element, along with the main branch and version \main\0, but does not check it out. If element-pname exists, it is moved aside to a .keep file, as explained earlier.
-ci [ -pti·me ]

Creates the new element and version \main\0, performs a checkout, and checks in a new version containing the data in view-private file or DO element-pname, which must exist. In Attache, local files corresponding to successfully checked-in versions are made read-only. You cannot use this option when creating a directory element.
With -ptime, mkelem preserves the modification time of the file being checked in. If you omit this option, the modification time of the new version is set to the checkin time.

MASTERSHIP OF THE MAIN BRANCH. Default: Assigns mastership of the element's main branch to the VOB replica that masters the main branch.


Assigns mastership of the main branch of the element to the VOB replica in which you execute the mkelem command. If your config spec includes -mkbranch lines or mkbranch rules that apply to the element, and you do not use the -nco option, mkelem creates these branches and assigns their mastership to the local VOB replica. mkelem also prints a note that these branches are explicitly mastered by the local replica; the output also displays the mastering replica of each associated branch type.

SUPPRESSING WARNING MESSAGES Default: Warning messages are displayed.


Suppresses warning messages.

EVENT RECORDS AND COMMENTS. Default: Creates one or more event records, with commenting controlled by your .clearcase_profile file (default: -cqe). See CUSTOMIZING COMMENT HANDLING in the comments reference page. Comments can be edited with chevent.

-c·omment comment | -cfi·le comment-file-pname |-cq·uery | -cqe·ach | -nc·omment

Overrides the default with the option you specify. See the comments reference page.


element-pname ...

The pathnames of one or more elements to be created. If you also specify the -ci option, each element-pname must name an existing view-private object. You cannot create a directory element with the same name as an existing view-private file or directory.


Examples including wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.

In cleartool single-command mode, cmd-context represents the command interpreter prompt. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt. In Attache, cmd-context represents the workspace prompt.

cmd-context mkelem -nc -eltype compressed_text_file rotate.c
Created element "rotate.c" (type "compressed_text_file").
Checked out "rotate.c" from version "\main\0".
cmd-context mkelem -nc -nco cm_add.c cm_fill.c msg.c
Created element "cm_add.c" (type "text_file").
Created element "cm_fill.c" (type "text_file").
Created element "msg.c" (type "text_file").
cmd-context mkelem -nc -ci test_cmd.c
Created element "test_cmd.c" (type "text_file").
Checked in "test_cmd.c" version "\main\1".
cmd-context mkelem -nc -eltype directory libs include
Created element "libs" (type "directory").
Checked out "libs" from version "\main\0".
Created element "include" (type "directory").
Checked out "include" from version "\main\0".
cmd-context mkeltype -nc -supertype binary_delta_file lib
Created element type "lib".
cmd-context cd libs
cmd-context co -nc .
Checked out "." from version "\main\1".
cmd-context mkelem -nc -nco -eltype lib libntx.lib libpvt.lib
Created element "libntx.lib" (type "lib").
Created element "libpvt.lib" (type "lib").


cc.magic, checkin, checkout, chpool, config_spec, lstype, mkdir, mkeltype, mkpool, protect, update

Feedback on the documentation in this site? We welcome any comments!
Copyright © 1999 by Rational Software Corporation. All rights reserved.