z/OS UNIX System Services File System Interface Reference
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


vn_rename — Rename a file or directory

z/OS UNIX System Services File System Interface Reference
SA23-2285-00

Function

The vn_rename renames a file or directory.

Environment on entry and exit

See Environment for PFS operations.

Input parameter format

vn_rename   (Token_structure,
             OSI_structure,
             Audit_structure,
             Name_length,
             Name,
             New_name_length,
             New_name,
             New_token_structure
             Return_value,
             Return_code,
             Reason_code)

Parameters

Token_structure
Supplied parameter
Type:
TOKSTR
Length:
Specified by TOKSTR.ts_hdr.cblen.

The Token_structure represents the file (vnode) that is being operated on. It contains the PFS's initialization token, mount token, and the file token. Refer to LFS/PFS control block structure for a discussion of this structure, and to the TOKSTR typedef in BPXYPFSI in Interface structures for C language servers and clients for its mapping.

OSI_structure
Supplied and returned parameter
Type:
OSI
Length:
Specified by OSI.osi_hdr.cblen.

The OSI_structure contains information that is used by the OSI operations that may be called by the PFS. See OSI services for more information.

It also contains MVS-specific information that needs to be passed to the PFS, including SMF accounting fields, a work area, a recovery area, and an optional pointer to an output ATTR structure. For more details on the OSI structure, see The OSI structure.

This area is mapped by the OSI typedef in BPXYPFSI in Interface structures for C language servers and clients.

Audit_structure
Supplied parameter
Type:
CRED
Length:
Specified by CRED.cred_hdr.cblen.

The Audit_structure contains information that is used by the security product for access checks and auditing. It is passed to most SAF routines that are invoked by the PFS.

Refer to Security responsibilities and considerations for a discussion of security processing, and to the CRED typedef in BPXYPFSI in Interface structures for C language servers and clients for the mapping of this structure.

Name_length
Supplied parameter
Type:
Integer
Length:
Fullword

A fullword that contains the length of Name. The name is between 1 and 255 bytes long.

Name
Supplied parameter
Type:
String
Length:
Specified by Name_length

An area, of length Name_length, that contains the file or directory name that is to be renamed. This name is not null-terminated.

New_name_length
Supplied parameter
Type:
Integer
Length:
Fullword

A fullword that contains the length of New_name. The name is between 1 and 255 bytes long.

New_name
Supplied parameter
Type:
String
Length:
Specified by New_name_length

An area, of length New_name_length, that contains the file or directory name to which the file or directory is to be renamed. This name is not null-terminated.

New_token_structure
Supplied parameter
Type:
Structure
Length:
Specified by the structure's TOKSTR.ts_hdr.cblen field.

New_token_structure represents the vnode of the directory that contains New_name.

Refer to LFS/PFS control block structure for a discussion of the use of this structure, and to the TOKSTR typedef in BPXYPFSI in Interface structures for C language servers and clients for its mapping.

Return_value
Returned parameter
Type:
Integer
Length:
Fullword
A fullword in which the vn_rename operation returns the results of the operation, as one of the following:
Return_value
Meaning
-1
The operation was not successful. The Return_code and Reason_Code values must be filled in by the PFS when Return_value is -1.
0
The operation was successful.
Return_code
Returned parameter
Type:
Integer
Length:
Fullword

A fullword in which the vn_rename operation stores the return code. The vn_rename operation returns Return_code only if Return_value is -1. For a complete list of supported return code values, see z/OS UNIX System Services Messages and Codes.

The vn_rename operation should support at least the following error values:
Return_code Explanation
EACCES The caller does not have write permission for one or both of the parent directories.
EBUSY The New_name could not be deleted, or the named file or directory could not be renamed because the PFS considers it to be in use.
EISDIR An attempt was made to rename a file to a directory.
ENAMETOOLONG The length of one of the names supplied was greater than the maximum supported name length for this PFS.
ENOENT Name was not found.
ENOTEMPTY New_name specified an existing directory that was not empty.
ENOTDIR Token_structure did not represent a directory, or an attempt was made to rename a directory to a file.
Reason_code
Returned parameter
Type:
Integer
Length:
Fullword

A fullword in which the vn_rename operation stores the reason code. The vn_rename operation returns Reason_code only if Return_value is -1. Reason_code further qualifies the Return_code value. These reason codes are documented by the PFS.

Implementation notes

Overview of vn_rename processing

The PFS renames a file or directory that is specified by Name in the directory that is represented by Token_structure to the name that is specified by New_name in the directory that is represented by New_token_structure.

Deleting files provides an overview of file deletion processing.

Specific processing notes
  • The system data fields of the Token_structure contain the PFS's file token for the file that is being renamed. The system data fields of the New_Token_structure contain the PFS's file token for the file that is named by New_name, if it exists.
  • If a directory entry does not already exist for New_name, the PFS creates it. If a directory entry for New_name already exists, the file or directory that is represented by this entry is deleted, as described for vn_remove or vn_rmdir, as appropriate.

    If New_name is an existing directory that is not empty, the PFS returns a Return_value of -1 and an Return Code of ENOTEMPTY.

    If the rename is successful, the directory entry for the old name is deleted.

  • The names that are passed to the PFS cannot be "." or "..".
  • For more information about the semantics of this operation for a POSIX-conforming PFS, refer to the rename() function in the POSIX .1 standard (IEEE Std 1003.1-1990).
Serialization provided by the LFS
The PFS is invoked with an exclusive latch for all of the vnodes involved in this operation. These include:
  • The old parent directory
  • The new parent directory
  • The file or directory that is specified by Name
  • If it already exists, the file or directory that is specified by New_name
Security calls to be made by the PFS

The PFS is expected to verify that the calling process has write permission for the directories that contain Name and New_name by calling SAF's Check Access callable service. If Name and New_name are themselves directories, the caller does not need write permission to these directories, only to the parent directories.

SAF's Check2Owners service is called whenever the sticky bit is on in the parent directory.

If the file that was previously known by New_name is deleted, invoke SAF's Audit callable service to record the deletion of the file.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014