The provisioning system can accommodate any number of components and can place them in any directory structure that you create. The number of components that can be created is only limited by the file system on the master server. Each file system limits the number of files that can be created, and by creating too many files in a single directory, you can exceed the file systems limitations. The relationship between components and files is not necessarily an equal ratio. For example, one component might exceed file system limitations if it has 100,000 files, and 100,000 components might fall within the file system limitations if none of the components contain files.
Exceeding file system limits might not result in a direct failure when the files are created. However, problems might arise in the form of increasingly severe performance degradation or unpredictable failures at other times.
Limits to the number of files that a directory can support vary by file system and can be influenced by how the operating system is configured. You can avoid overloading a directory by understanding your file system's limitations and placing components into smaller subdirectories, rather than into a single, large directory. A conservative practice to use when creating components is to place no more than 30,000 files in a single directory.
The system#directory component type represents a collection of files and folders that are taken from a target server. The system#directory component type includes installation, uninstallation, and snapshot procedures.
The system#directory component type defines the following variables:
installName – The name to use for the resource when it is installed. The default value is the name of the component.
installPath – The path in which to install the resource. The default value is the value of the installPath variable of the container component.
installPermissions – The permissions to assign to the resource when it is installed. See the chmod(1M) man page. The default value is empty.
installUser – The owner of this resource when it is installed. The default value is empty.
installGroup – The group to assign to this resource when it is installed. The default value is empty.
installDiffDeploy – Specifies whether the resource should be deployed in differential deploy mode. The default value is TRUE.
overrideRsrcInstallPath – The absolute path in which to install the resource. If not defined, the resource is installed in the path specified by installPath. This variable is not commonly used so that installPath can be used to specify the path in which to install both the component and the resource.
installDeployMode – Specifies whether to add files to the directory (ADD_TO) or replace the files in the directory (REPLACE). The default value is REPLACE.
|
UNIX Systems |
Microsoft Windows Systems |
---|---|---|
Root Path |
/ |
List of physical drives on the host or network are mapped to a drive letter. Removable media is not shown. |
Delimiter |
/ |
\ |
Ordering |
Alphabetical with directories appearing first |
|
Selection Type |
User can select a directory for check-in. Double click a directory to view its contents. |
|
Sample Path |
/foo/foo/ |
C:\foo\foo\ |
Filters |
None |
|
Special |
Links display their local name and the location pointed to: foo/->/usr/bar/ |
|
The following procedures are defined for the system#directory component type:
default install block – Deploys the contained file based on the state of the variables. No snapshots are captured.
markOnly install block – Marks the system to indicate that a new version of the component is installed. No resources are transferred, and no snapshots are captured.
default uninstall block – Undeploys the contained file from the location to which it was originally deployed.
markOnly uninstall block – Marks the system to indicate that the current version of the component has been uninstalled. The component's resources are not actually removed from the target host.
default snapshot block – Captures a snapshot of the deployed file. Because the default install block does not capture the file by default, container components must call this routine explicitly if you want a snapshot.