Open System Services Porting Guide (G06.29+, H06.06+, J06.03+)

Using Symbolic Links
Similar to a hard link, a symbolic link allows a file to have multiple logical names. The file named
in a symbolic link actually contains the name of the file that contains the data. A symbolic link
permits links across file systems.
Symbolic links are implemented in the OSS environment, but only for OSS pathnames. You cannot
create symbolic links in the /G directory. The OSS functions supporting symbolic links include
symlink(), readlink(), lchmod(), lchown(), lstat(), and lstat64(). Supporting
interoperability between the OSS and Guardian environments, these functions are callable from
Guardian processes and can be used with Guardian objects.
The symlink() function creates a symbolic link to a file. Symbolic links can be created only in
the OSS file system, but the file named in the symbolic link can be an OSS file or a Guardian file
(using /G syntax).
The readlink() function reads the value of a symbolic link by placing the contents of the symbolic
link named by the path parameter into the buffer parameter. To use readlink(), the calling
process must have execute (search) permission for the directory containing the link. The readlink()
function cannot be used on an object in the Guardian file system (/G).
The lchmod() function is an HP extension function that sets the access permissions of a file
specified by the path parameter according to the bit pattern specified by the mode parameter.
If the final component of the path parameter refers to a symbolic link, the lchmod() function
changes access permissions for the symbolic link instead of the file to which it refers. To change
the file access permissions of a file or directory, the effective user ID of the process must match the
super ID or the owner of the file, or its effective user ID or one of its group affiliations must qualify
it for membership in the Safeguard SECURITY-OSS-ADMINISTRATOR group.
The lchown() function changes the owner and group of a file. If the final component of the path
parameter names a symbolic link, the lchown() function changes the ownership of the symbolic
link instead of the file or directory to which the symbolic link refers. Only a process that has an
effective user ID equal to the super ID or to the file owner, or that has an effective user ID or group
affiliation qualifying for membership in the Safeguard SECURITY-OSS-ADMINISTRATOR group
can use the lchown() function to change the group of a file. However, processes that have an
effective user ID equal to the file owner can only change the group of a file to a group to which
they belong (their effective group or one of their supplementary groups).
The lstat() and lstat64() functions obtain information about the symbolic link whose name
is pointed to by the path parameter, or about any file pointed to by the path parameter. When
using these functions, read, write, and execution permission for the specified file are not required.
For Guardian disk files, the lstat(), lstat64(), and stat() functions are functionally similar.
The functions that refer only to the symbolic link, rather than to the object to which the link refers,
are the link(), lstat(), lstat64(), mknod(), readlink(), remove(), rename(),
rmdir(), and unlink() functions.
Refer to the symlink(), readlink(), lchmod(), lchown(), lstat(), and lstat64()
reference pages, either online or in the Open System Services System Calls Reference Manual.
The Guardian procedures that map OSS pathnames and Guardian filenames
(FILENAME_TO_PATHNAME_ and PATHNAME_TO_FILENAME_) support symbolic links. Detailed
information on using these Guardian procedures is located in the Guardian Procedure Calls
Reference Manual.
Porting Servers and Demons
A common performance enhancement during porting is to convert servers that create many short-lived
child processes (which handle one request each) into servers that create a few long-lived child
processes (perhaps one per processor) that handle a stream of requests one at a time. With
additional logic for load-leveling and fault recovery, the ported application can take advantage
of NonStop system fundamentals.
Porting Servers and Demons 103