The fn_ctx_rename() operation binds the reference currently bound to oldname relative to ctx, to the name newname, and unbinds oldname. newname is resolved relative to the target context (that named by all but the terminal atomic part of oldname).

If exclusive is 0, the operation overwrites any old binding of newname. If exclusive is nonzero, the operation fails if newname is already bound.

fn_ctx_rename() returns 1 if the operation is successful, 0 otherwise.

fn_ctx_rename() sets status as described FN_status_t(3XFN) and xfn_status_codes(3XFN).

The only restriction that XFN places on newname is that it be resolved relative to the target context. XFN does not specify further restrictions on newname. For example, in some implementations, newname might be restricted to be a name in the same naming system as the terminal component of oldname. In another implementation, newname might be restricted to be an atomic name.

Normal resolution always follows links. In an fn_ctx_rename() operation, resolution of oldname continues to the target context; the terminal atomic name is not resolved. If the terminal atomic name is bound to a link, the link is not followed and the operation binds newname to the link and unbinds the terminal atomic name of oldname.

In naming systems that support attributes and store the attributes along with the names, the unbind of the terminal atomic name of oldname also removes its associated attributes. It is implementation-dependent whether these attributes become associated with newname.

See attributes(5) for descriptions of the following attributes:

FN_composite_name_t(3XFN), FN_ctx_t(3XFN), FN_ref_t(3XFN), FN_status_t(3XFN), fn_ctx_bind(3XFN) fn_ctx_unbind(3XFN), xfn(3XFN), xfn_status_codes(3XFN), attributes(5)

The implementation of XFN in this Solaris release is based on the X/Open preliminary specification. It is likely that there will be minor changes to these interfaces to reflect changes in the final version of this specification. The next minor release of Solaris will offer binary compatibility for applications developed using the current interfaces. As the interfaces evolve toward standardization, it is possible that future releases of Solaris will require minor source code changes to applications that have been developed against the preliminary specification.