fn_ctx_rename(3N) manual page
Table of Contents
fn_ctx_rename - rename the name of a binding
cc [ flag
... ] file ... -lxfn [ library ... ]
#include <xfn/xfn.h>
int fn_ctx_rename(FN_ctx_t *ctx, const FN_composite_name_t *oldname,
const FN_composite_name_t *newname, unsigned int exclusive, FN_status_t
*status);
MT-Safe
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(3N)
and xfn_status_codes(3N)
.
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.
FN_composite_name_t(3N)
, FN_ctx_t(3N)
, FN_ref_t(3N)
,
FN_status_t(3N)
, fn_ctx_bind(3N)
, fn_ctx_unbind(3N)
, xfn(3N)
, xfn_status_codes(3N)
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.
Table of Contents