| Previous | Contents | Index |
When operating in POSIX-compliant mode, the C RTL function
decc$to_vms
converts a POSIX pathname into the RMS quoted pathname format. If an
RMS quoted pathname is passed to either
decc$from_vms
or
decc$translate_vms
, these functions change the quoted pathname into a POSIX pathname by
removing the quotes and the
^UP^
prefix (so, for example,
"^UP^a/b"
becomes
a/b
). When not in POSIX-compliant mode, these functions operate as they
did previously.
12.3.3 Symbolic Link Functions
Table 12-1 lists and describes the symbolic-link functions in the HP C Run-Time Library (RTL). For more detailed information on each function, see the Reference Section.
| Function | Description |
|---|---|
| lchown | Changes the owner and/or group of a file. If the file is a symbolic link, the owner of the symbolic link is modified (in contrast to chown which would modify the file that the symbolic link points to). |
| lstat | Retrieves information about the specified file. If the file is a symbolic link, information about the link itself is returned (in contrast to stat , which would return information about the file that the symbolic link points to). |
| readlink | Reads the contents of a symbolic link and places them into a user-supplied buffer. |
| realpath | Returns an absolute pathname from the POSIX root. |
| unlink | Deletes a symbolic link from the system. |
| symlink | Creates a symbolic link containing the specified contents. |
In addition to the previously described new functions, the following C RTL functions are modified to support symbolic links:
creat
When a new version of a file is created, and the named file already exists as a symbolic link, the file to which the symbolic link refers is created.
open
If the file_spec parameter refers to a symbolic link, the open function opens the file pointed to by the symbolic link.
delete , remove
When delete or remove is used to delete a symbolic link, the link itself is deleted, not the file to which it refers.
Also, in accordance with the Open Group specification, an
errno
value of ELOOP is returned if a loop exists in the resolution of a
symbolic link.
12.3.5 Non POSIX-Compliant Behavior
12.3.5.1 Multiple Versions of Files
When using POSIX-compliant pathnames, if multiple versions of a file
exist, you can access only the latest version of the file. Deleting a
file results in the deletion of only the highest-numbered version of a
file.
12.3.5.2 Ambiguous Filenames
If the file "a" and directory "a.DIR;1" both exist in a directory, users in POSIX-compliant mode will have the following access:
As previously described, a quoted pathname is a POSIX pathname prefixed with the tag string ^UP^ and enclosed with opening and closing quotation marks. In addition, any quotation marks present in the POSIX pathname need to be doubled, consistent with the way DCL handles quoted strings.
Quoted pathnames are allowed in the primary name, default name, and/or related names. By identifying the ^UP^ prefix and the opening and closing quotation marks, RMS interprets the rest of the characters as a standard POSIX pathname (with the exception that every pair of quotation marks in the pathname is treated as a single quotation mark). If RMS detects a quoted pathname, then the expanded and resultant file specifications are supplied by RMS as quoted pathnames as well.
The components of the returned quoted pathname are referenced by the NAM or NAML as follows:
The dir, name, and type fields can be NUL.
For example, the quoted pathname "^UP^/a/b.c" consists of the following components:
The node is NUL
The dev is "^UP^
The dir is /a/
The name is b
The type is .c
The version is "
The following RMS routines support symbolic links:
The following restrictions apply to RMS processing of POSIX pathnames:
Applications, including DCL commands and utilities, need the ability to control RMS behavior when RMS encounters symbolic links during typical file operations. Specifically, applications need to be able to specify whether or not a pathname stored in a symbolic link should be included as part of pathname processing and directory searches. Furthermore, applications need to be able to specify different behavior depending on how the symbolic link is encountered.
Various NAML$L_INPUT_FLAGS flags are now provided to allow necessary application flexibility:
For absolute POSIX pathnames, RMS needs to interpret the leading '
/
' as a UNIX-style root. POSIX expects that everything starts from this
POSIX root. The POSIX root can be established with the GNV installation
procedure or with the new DCL command, SET ROOT.
12.5.1 Suggested Placement of the POSIX Root
During the GNV installation and configuration procedure or when using the SET ROOT command, you need to provide a location for the POSIX root for the system. By default, the GNV installation establishes the location of the root at SYS$SYSDEVICE:[PSX$ROOT]. You can accept this directory as the root or specify another directory. GNV then creates a mount point in " /mnt " (which is directory " mnt " in your POSIX root directory) for each disk device on your system.
If you accept the default for the root, or specify any other directory that is not the top-level directory of a device, then files that do not reside in the directory tree under the root directory will be inaccessible using a POSIX pathname, unless the device containing the root directory is mounted by means of a mount point under the root. (This mount point is automatically generated by GNV during the configuration.) Be aware, though, that when such a mount point is created, directory tree traversals can result in a loop. See Figure 12-1.
Figure 12-1 POSIX Root Placement
DKB0 -> 000000
|
+-----+----------+
| |
PSX$ROOT other things
|
mnt
|
+----------+-----------+
| | |
DKB1 DKB2 DKB0
|
+-----+----------+
| |
PSX$ROOT other things
|
An alternative is to specify the top-level directory, the Master File Directory (MFD), of a device as the root and not create a mount point for that device. This makes all of the files on the device accessible via POSIX pathnames. However, using the MFD of a device (especially the system device) as the root means that all of the files in the MFD are visible when a user displays the files in a root directory (such as "ls /"). GNV users will see OpenVMS files that they might not expect to see; similarly, DCL users will see UNIX files they might not expect to see. Also, the MFD of a device might not be accessible to most general users, resulting in unexpected failures.
We recommend you use the supplied default root directory.
12.5.2 The SET ROOT Command
The SET ROOT command has the following format:
SET ROOT device-name:directory-spec |
This command defines the POSIX root. In POSIX pathname processing mode, RMS and the C RTL will treat the leading ' / ' of a pathname as referring to the defined root. By default, the root is SYS$SYSDEVICE:[PSX$ROOT].
The root definition does not persist across a reboot.
The SET ROOT command has the following qualifiers:
/LOG (default)
/NOLOG
Controls whether the SET ROOT command displays a success indication after the root definition is set./PROCESS
/NOPROCESS
Sets the root for the current process and overrides the system definition of the root for the process. Requires SYSNAM privilege.Restriction: For this SDK, processes created by this process do not inherit the process definition of the root.
Specifying /NOPROCESS removes the process definition of the root and causes the process to revert back to the system definition of the root.
/SYSTEM
Sets the root for the system. Requires SYSNAM prvilege.Processes that were executing before this command is executed will continue to use the previous definition of the root.
The /NOPROCESS, /PROCESS, and /SYSTEM qualifers are mutually exclusive, and one of them must be specified.
The SHOW ROOT command displays the current value of the system root and, if defined, the process root.
This command has the following format:
SHOW ROOT |
On UNIX systems, the current working directory is a directory that is used in pathname resolution for pathnames that do not begin with a slash.
If RMS encounters a symbolic link, the directory in which the symbolic link is found is the current working directory for the purposes of pathname resolution.
For the resolution of POSIX pathnames passed directly to RMS, the
current working directory is the current OpenVMS default directory for
the process. If the OpenVMS default directory is not a single directory
(for example, the directory specification includes a search list), then
the current working directory is the first directory encountered
through the search list.
12.7 Establishing Mount Points
Two new utilities, mnt and umnt provide a way for a user to mount and dismount file systems from mount points. Only privileged users who can execute a sys$cmkrnl can mount and dismount file systems. These utilities are shipped as part of GNV.
The utilities maintain their own logical name table of mount points, which is used to display currently available mount points upon request.
The interfaces for these utilities are as follows:
mnt
List existing mount points.
mnt file_system mount_point
Mount file system file_system on mount point mount_point.
umnt mount_point
Unmount the file system mounted on mount point mount_point.
umnt file_system
Unmount the file system file_system from its mount point.
umnt -A
Unmount all file systems from their mount points.
Note that both OpenVMS file specifications and POSIX pathnames are
allowed for the arguments.
12.8 NFS
In TCP/IP Services for OpenVMS, Version 5.4 and older, there was
limited symbolic link support in the NFS client for the purpose of
backing up symbolic links from a UNIX server into an OpenVMS saveset
and correctly restoring them. The client used an application ACE to
flag a file as a symbolic link. In Version 5.5, the client preserves
this behavior for an ODS-2 mount. For an ODS-5 mount, it creates a
symbolic link when it sees the application ACE. This allows savesets
created with older versions of the client to still be restored with
newer versions.
12.9 DCL
OpenVMS DCL commands and utilities behave in predictable ways when encountering symbolic links. Usually, the symbolic link is followed; for example, if symbolic link LINKFILE.TXT points to file TEXT.TXT, then entering the command "type LINKFILE.TXT" displays the text contained in TEXT.TXT.
The symbolic link is followed even if the symbolic link itself is not directly specified; for example, if a symbolic link that references a directory is encountered when processing a command such as " dir [...]*.TXT ", any files with a type of " .TXT " that exist in the pointed-to directory (and its subdirectories) would be displayed. (Note: For this SDK, during directory wildcard operations, symbolic links are not examined to see if they refer to directories.)
There are some cases, however, where the symbolic link should not be followed by default. Also, it is sometimes desirable to give the user the option of whether or not to follow a symbolic link.
The following commands either do not follow the symbolic link by default and/or provide an option whether or not to follow a symbolic link.
BACKUP
When a symbolic link is encountered during a backup operation, the symbolic link itself is copied. This is true for all backup types---physical, image and file.
COPY
/SYMLINK /NOSYMLINK (default)
If an input file is a symbolic link, the file referred to by the symbolic link is the file that is copied.
The /SYMLINK qualifier indicates that any input symbolic link is copied.
CREATE
/SYMLINK="text"
Creates a symbolic link containing the specified text without the enclosing quotation marks.
If the created symbolic link is subsequently encountered during any filename processing, the contents of the symbolic link are read and treated as a POSIX pathname specification.
No previous version of the symbolic link can exist.
DELETE
If an input file specification parameter is a symbolic link, the symbolic link itself is deleted.
DIRECTORY
/SYMLINK (default) /NOSYMLINK
If an input file specification parameter is a symbolic link, the displayed file attributes are those of the symbolic link itself. If any file attribute is requested, then the contents of the symbolic link are also displayed with an arrow appearing between the filename and the contents (for example, LINK.TXT -> FILE.TXT).
The /NOSYMLINK qualifier indicates that if an input file specification is a symbolic link, then the file attributes of the file to which the symbolic link refers are displayed; the displayed name is still the name of the symbolic link itself.
DUMP
/SYMLINK /NOSYMLINK (default)
If an input file is a symbolic link, the file referred to by the symbolic link is the file that is dumped.
The /SYMLINK qualifier indicates that any input symbolic link is dumped.
PURGE
If an input file specification is a symbolic link, the symbolic link itself is purged. Because only one version of a symbolic link can exist, this command has no effect on that file.
RENAME
If an input file specification is a symbolic link, the symbolic link itself is renamed.
If the output file specification is a symbolic link, the operation fails.
SET FILE
/SYMLINK /NOSYMLINK (default)
If an input file is a symbolic link, the file referred to by the symbolic link is the file that is set.
The /SYMLINK qualifier indicates that the symbolic link itself is set.
|
GNV is the mechanism by which the Open Group utilities are provided on OpenVMS systems. GNV is an open source project with updates released on the Sourceforge web site. GNV is also available on the OpenVMS Open Source CD.
Because GNV relies on the C RTL for all file access, no modifications
are made to GNV for its provided utilities to behave as defined by the
Open Group specification for symbolic links. To make use of the new
symbolic-link and POSIX pathname support features, users should set the
C RTL DECC$POSIX_COMPLIANT_PATHNAMES feature logical appropriately,
before invoking BASH.
12.11 Restrictions
The following are known restrictions with symbolic link support:
Converts a character string to a long integer.
#include <stdlib.h>long a64l (const char *s);
s
Pointer to the character string that is to be converted to a long integer.
The a64l and l64a functions are used to maintain numbers stored in base-64 ASCII characters as follows:
- a64l converts a character string to a long integer.
- l64a converts a long integer to a character string.
Each character used for storing a long integer represents a numeric value from 0 through 63. Up to six characters can be used to represent a long integer.
The characters are translated as follows:
- A period (.) represents 0.
- A slash (/) represents 1.
- The numbers 0 through 9 represent 2 through 11.
- Uppercase letters A through Z represent 12 through 37.
- Lowercase letters a through z represent 38 through 63.
The a64l function takes a pointer to a base-64 representation, in which the first digit is the least significant, and returns a corresponding long value. If the string pointed to by the s parameter exceeds six characters, a64l uses only the first six characters.
If the first six characters of the string contain a null terminator, a64l uses only characters preceding the null terminator.
The a64l function translates a character string from left to right with the least significant number on the left, decoding each character as a 6-bit base-64 number.
If s is the NULL pointer or if the string pointed to by s was not generated by a previous call to l64a , the behavior of a64l is unspecified.
See also l64a .
n Upon successful completion, the long value resulting from conversion of the input string. 0L Indicates that the string pointed to by s is an empty string.
| Previous | Next | Contents | Index |