File specification syntax
There are some syntax rules that you need to know about when entering file specification parameters such as filespec, sourcefilespec, and destinationfilespec.
The following are the syntax rules:
Do not use wildcards as part of the file space name or anywhere in the destinationfilespec. The one exception to this rule is the set access command where wildcards are permitted in the two lowest levels of the file spec.
- Example: Allow access to all files in all directories in and subordinate to the /home directory:
set access backup /home/* * * set access backup /home/*/* * *With UNIX clients, do not use wildcards in a directory path name, for example:
- Example: Allow access to all files in all directories in and subordinate to the d:\test directory:
set access backup d:\test\* * * set access backup d:\test\*\* * *
- There is a maximum number of file specifications per command:
- The Query commands can accept only one file specification.
- The restore and retrieve commands can accept a source file specification and a destination file specification.
- There is a limit of 20 operands on some commands. This
limit is to prevent excessive sessions that are caused when wildcards are expanded by the UNIX shell command processor. You can prevent shell expansion from causing you to go over the 20-operand limit by placing quotation marks around your source filespec expansion characters for restore commands.Note: Using quotation marks has the side affect of causing a no-query restore.
You can use the removeoperandlimit option to specify that the backup-archive client removes the 20-operand limit. If you specify the removeoperandlimit option with the incremental, selective, archive, or backup image command, the 20-operand limit is not enforced and is restricted only by available resources or other operating system limits.
- The length of a file specification is limited.
- On AIX, Solaris, and Mac: The maximum number of characters for a file name is 255. The maximum combined length of the file name and path name is 1024 characters. The Unicode representation of a character can occupy several bytes, so the maximum number of characters that a file name might contain can vary.
- On Linux: The maximum length for a file name
is 255 bytes. The maximum combined length of both the file name and
path name is 4096 bytes. This length matches the PATH_MAX that is
supported by the operating system. The Unicode representation of a
character can occupy several bytes, so the maximum number of characters
that comprises a path and file name can vary. The actual limitation
is the number of bytes in the path and file components, which might
correspond to an equal number of characters.
On Linux: For archive or retrieve operations, the maximum length that you can specify for a path and file name (combined) remains at 1024 bytes.
- The maximum number of bytes for a file name and file path when combined is
6255. However, the file name itself cannot exceed 255 bytes. Furthermore, directory names (including
the directory delimiter) within a path are limited to 255 bytes. The Unicode representation of a
character can occupy several bytes, so the maximum number of characters that a file name might
contain can vary.
When using the open file support feature with VSS, the backup-archive client adds the snapshot volume name to the path of the objects being processed. The resulting path (snapshot volume name plus object path) must adhere to the limits shown. The snapshot volume name can be up to 1024 bytes.
When you enter the sourcefilespec, if the directory name ends with /, then /* is implied.
When you enter the sourcefilespec, if the directory name ends with \, then \* is implied.
When you enter a destinationfilespec, if the name ends with /, then it is considered a directory, otherwise it is considered a file.
When you enter a destinationfilespec, if the name ends with \, then it is considered a directory, otherwise it is considered a file.
The following example illustrates these two rules. Even though mydir and yourdir are directories, the command will fail because /* is implied after mydir, and yourdir is considered a file.
restore /home/mydir/ /away/yourdir
The following example illustrates these two rules. Even though mydir and yourdir are directories, the command will fail because \* is implied after mydir, and yourdir is considered a file.
restore c:\home\mydir\ c:\away\yourdir
If a file specification does not begin with a directory delimiter, the file specification is assumed to be a subdirectory of the current working directory. The client appends the file specification to the working directory to build the complete path.
For example, if the current working directory is /home/me and the command is
dsmc res "/fs/dir1/*" mydir/, the complete restore path is this: /home/me/mydir
For example, if the current working directory is c:\home\me and the command is
dsmc res c:\fs\dir1\ mydir\, the complete restore path is this: c:\home\me\mydir
- The only command
that accepts a simple file space name is the incremental command. The following example is valid: The following example is not valid, because the command is the selective command:
dsmc i /Users
dsmc sel /Users
- When a file specification contains spaces,
it must be enclosed in quotation marks. For example:
dsmc sel "x:\dir one\file1"
When a file specification ends with a backslash and is enclosed in quotation marks, an extra backslash (\) must be added to the end of the file specification. If an extra backslash is not added, the filespec will not be processed correctly, and the operation might cause unexpected results.
The following example is incorrect:
dsmc sel "x:\dir one\"
The following example is correct:
dsmc sel "x:\dir one\\"
Here is an example of restoring the contents of one directory to another, when both directory names contain spaces:
dsmc rest "x:\dir one\\" "x:\dir two\\"
- Microsoft Dfs volumes are accessed using the standard UNC names. The following
are examples of valid syntax to access MS Dfs volumes: