Getting Started with QNX Neutrino - QNX Software Systems

Alphabetical listing of connect and I/O functions
© 2009, QNX Software Systems GmbH & Co. KG.
Returns: The status via the helper macro _RESMGR_STATUS and the data via message
reply.
io_rename()
int io_rename (resmgr_context_t *ctp, io_rename_t *msg,
RESMGR_HANDLE_T *handle, io_rename_extra_t *extra)
Classification: Connect
Default handler: none
Helper functions: iofunc_rename()
Client function: rename()
Messages: _IO_CONNECT with subtype _IO_CONNECT_RENAME
Data structure:
struct _io_connect {
// internal fields (as described above)
uint16_t path_len;
uint8_t extra_type;
uint16_t extra_len;
char path [1];
};
struct _io_connect_link_reply {
uint32_t reserved1 [2];
uint8_t eflag;
uint8_t reserved2 [3];
uint32_t umask;
uint16_t nentries;
uint16_t path_len;
};
typedef union _io_rename_extra {
char path [1];
} io_rename_extra_t;
typedef union {
struct _io_connect
connect;
struct _io_connect_link_reply link_reply;
} io_rename_t;
Description: Performs the rename operation, given the new name in path and the
original name in the path member of the passed extra parameter. Implementation note:
the pathname of the original name is given (rather than an OCB) specifically for the
case of handling a rename of a file that’s hard-linked to another file. If the OCB were
given, there would be no way to tell apart the two (or more) versions of the
hard-linked file.
This function will be called only with two filenames that are on the same filesystem
(same device). Therefore, there’s no need to check for a case where you’d return
EXDEV. This doesn’t prevent you from returning EXDEV if you don’t wish to perform
the rename() yourself (for example, it may be very complicated to do the rename
operation from one directory to another). In the case of returning EXDEV, the shell
246 Chapter 5 • Resource Managers April 30, 2009