The protect command sets the owner, group, or permissions for one or more elements, shared derived objects, or named VOB objects. This information is maintained in the VOB database.
The main use of protect is to control access by standard programs to an element or object's data. For example, you can make some elements readable by anyone and make others readable by only their group members.
Modifying the permissions of an element changes the permissions of all of its source containers and (if applicable) its cleartext containers. That is, the change affects all versions, not just the version selected by the current view. There is no way to change the permissions of an individual version.
Some forms of protect affect ClearCase access. For example, a checkout or checkin is permitted only if the user is the element's owner or is a member of the element's group.
This command does not affect view-private objects. For this reason, entering a protect command sometimes seems to have no effect:
You can change the permissions on any view-private object (including a checked-out version), with the standard operating system commands.
A winked-in DO is not really a view-private object, but it behaves like one (so that users in different views can build software independently). Moreover, changing the permissions of a winked-in DO actually converts it to a view-private file in your view. See IBM Rational ClearCase Guide to Building Software.
The initial owner of an element is the user who creates it with mkelem or mkdir. The initial owner of a named VOB object is the user who creates it. The initial owner of a derived object is the user who builds it with clearmake. When the derived object is winked in and becomes shared, its data container is promoted to a VOB storage pool. This process preserves the derived object's ownership, no matter who performs the build that causes the winkin.
For a list of operations that can be performed by an element's owner, see the permissions reference page .
The initial group of an element or named VOB object is the principal group of its creator. The new group specified in a protect –chgrp command must be one of the groups on the VOB's group list.
See the permissions reference page for a list of operations that can be performed by members of an element's or derived object's group.
The read and execute permissions of an element or a shared derived object control access to its data in the standard manner. The permissions are also applied to all its associated data containers. Read and execute permissions do not apply to non-file-system objects such as branch types and hyperlinks.
The meaning of the write permission varies with the kind of object:
For a file element, write permission settings are ignored. To obtain write permission to a file element, you must check it out (see the checkout reference page).
For a directory element, write permission allows view-private files to be created within it. ClearCase permissions control changes to the directory element itself. (See the permissions reference page.)
For a shared derived object, write permission allows it to be overwritten with a new derived object during a target rebuild. (The shared derived object is not actually affected; rather, the view sees the new, unshared derived object in its place.)
Changing the protection of a global type or a local copy of a global type changes the protection of the global type and all its local copies. You must have permission to change the protection of the global type.
If the protection cannot be changed on one or more of the local copies, the operation fails and the global type's protection is not changed. You must fix the problem and run the protect command again.
For more information, see the IBM Rational ClearCase Administrator's Guide.
UNIX and Linux: The argument must be in chown(1) format. The owner may be either a decimal user ID or a login name found in the passwd(4) file.
Windows: The login-name must specify a domainwide user account.
UNIX and Linux: The argument must be in chgroup(1) format. The group may be either a decimal group ID or a group name found in the group(4) file.
Windows: The group must be registered in the domainwide account database.
Specify symbolic permissions in one or more of the following forms:
[identity]-permission
[identity]=permission
where identity is any combination of
When identity is unspecified, its default value is a.
permission can be any combination of
To combine the forms, separate them with a comma (no white space). For example, to specify read and write permissions for an element's owner and no access by group or other:
cmd-context protect –chmod u=rw,go-rwx test.txt
Absolute permissions are constructed from the OR of any of the following octal numbers:
If you specify multiple pname arguments, but you do not have permission to change the permissions on a particular object, protect quits as soon as it encounters this error.
The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.
The Windows examples that include 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 UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.
cmd-context protect
–chmod +r hello.c Changed protection on
"hello.c".
cmd-context protect –recurse –chgrp user src
Changedprotection on "src".
Changed protection on "src/cm_fill.c".
Changed protection on "src/convolution.c".
Changed protection on "src/hello.c".
Changed protection on "src/msg.c".
Changed protection on "src/util.c".
cmd-context protect
–chown tester brtype:qa_test Changed protection
on "qa_test".
cmd-context protect
–chmod 770 hello Changed protection on
"hello".