Behavior of automounted VOBs
Users will notice little or no difference when VOB automounting is enabled. Whenever a VOB is referred to, it is automatically mounted if it is not already mounted. VOB mounts that have not been accessed for the default timeout period are unmounted automatically.
- Automounting affects which VOBs users can assume to be mounted at any given time. A small number of cleartool commands might act on multiple VOBs and their scopes might be different when not all VOBs are mounted. This situation is discussed in more detail in Command considerations.
- When automounting is enabled, the operating system's autofs file system manages the specified mount point. The only operations that are supported by autofs beneath a mount point are mount and unmount. Users or programs cannot complete other operations directly in that directory and might notice some different behaviors because of that restriction.
Actions that cause VOBs to be automounted
Any fully qualified path name reference to a directory or file in a VOB causes automounting. Relative path names that go through the VOB tag directory also cause automounting. Use of these path names might be the result of a direct user action such as issuing shell commands like cd or ls. Browsing into a directory in a graphical interface, including the VersionVault Explorer, or acting on a specific file object in such a GUI will also cause a mount, if the VOB is required. Makefile commands, scripts, or search path environment variables might refer to VOB paths. If HCL VersionVault MultiSite is installed, multitool commands might also cause automounting.
As with an explicit cleartool mount, users do not have to be set to a view context to automount the VOB. However, a view context is still required to access the files and directories in the VOB.
Command considerations
The following table lists some specific command considerations.
| Command | Consideration |
|---|---|
| cleartool mount | The cleartool mount command still mounts an unmounted VOB. VOBs that are mounted by using the cleartool mount command and listed in the automount map are still automatically unmounted by autofs. |
| Commands that include VOB paths on input and output | The cleartool commands that take a path name argument might trigger automounting, but commands such as cleartool lsvob or lsactivity that provide VOB paths in their output will not cause those VOBs to be mounted. |
| Commands that include the -invob option | Many commands act on the current VOB (which is based on a working directory), and the actions of setting to a view and navigating to that directory would have already caused that VOB to mount. Some commands accept the -invob option, rather than inferring the VOB from the working environment. The VOB that is named with the -invob option is automounted. |
| Commands with the -avobs option |
A small subset of cleartool commands accept the -avobs option. This acceptance means that the command works with and outside the current VOB. Before you issue a command, consider all versions in the VOBs that are currently mounted on the local host. In the absence of automounting, this command and option might typically include all the public VOBs that were mounted when HCL VersionVault was started on that host. An optional CLEARCASE_AVOBS environment variable might be defined to designate a specific, smaller list of VOBs to be considered as the scope of the -avobs option. Because VOBs that can be automounted might not be mounted or were automatically unmounted, it is possible that a command that uses the -avobs option might not find as many VOBs mounted as it did previously. You can help ensure that the planned scope of a command can be realized: update the cleartool commands that accept the -avobs option so that when automounting is enabled, the CLEARCASE_AVOBS list is interpreted to mean that mounting of those VOBs must be triggered, if necessary. Specify CLEARCASE_AVOBS as a list of VOB tags separated by commas, white spaces, or colons. The cleartool commands to which the previous information applies are as follows:
|
| cleartool lsprivate | The cleartool lsprivate command lists file system objects that belong to a
dynamic view. Even though these objects are stored in the view's private storage area, they are
listed with path names in one or more VOBs. This command already handles the case of a VOB that is
not currently mounted, it can list the view-private files but flags them with a "#" in the command
output. Flagging might occur more commonly when automounting enabled. See the following example of
such output:
|
Public and private VOBs
The automounter can mount both public and private VOBs. The cleartool mount command enforces this requirement: mounting a private VOB requires ownership of the VOB storage directory. Autofs does not enforce this requirement at mount time; all actions that refer to the VOB tag path name mount a private VOB.
For private VOBs, the cleartool mount command also requires ownership of the VOB tag mount-over directory or allows a root user to mount the private VOB. When a private VOB is automounted, that directory is owned by the root user, and a subsequent attempt by the private VOB owner to mount the VOB using the cleartool mount fails with a permission error. Automounting continues to work, however.