Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform

Кёртен Роб

Чтобы удостовериться, что файл был открыт в режиме, совместимом с операцией чтения, надо вызвать вспомогательную функцию iofunc_read_verify. Также, следует вызвать функцию iofunc_sync_verify, чтобы проверить, надо ли синхронизировать данные с носителем.

Возвращает: Число считанных байтов или код завершения, при помощи вспомогательного макроса _IO_SET_READ_NBYTES, а также собственно данные — ответным сообщением.

В качестве примера с возвратом только данных см. ниже раздел «Простой пример функции io_read». Более сложный пример с одновременным возвратом как данных,

так и элементов каталогов, см. в параграфе «Возврат элементов каталога» раздела «Дополнительно».

io_readlink

int io_readlink(resmgr_context_t *ctp, io_readlink_t *msg,

 RESMGR_HANDLE_T *handle, void* reserved)

Классификация: Функция установления соединения

Обработчик по умолчанию: Нет

Вспомогательные функции: iofunc_readlink

Клиентская функция: readlink

Сообщения: IO_CONNECT, подтип IO_CONNECT_READLINK

Структура данных:

struct _io_connect {

 // Внутренние поля (как описано выше)

 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 {

 struct _io_connect connect;

 struct _io_connect_link_reply link_reply;

} io_open_t;

Описание: Отвечает за чтение содержимого символьной связи (линка), как определено полем path входной структуры. Возвращаемые байты представляют собой содержимое символьной связи; возвращаемый код состояния представляет собой число байт в ответе. Допустимый возврат должен быть сделано только для символьной связи. Все другие доступы должны возвратить код ошибки.

Возвращает: Код завершения, при помощи вспомогательного макроса _RESMGR_STATUS, и данные в ответном сообщении.

io_rename

int io_rename(resmgr_context_t *ctp, io_rename_t *msg,

 RESMGR_HANDLE_T *handle, io_rename_extra_t* extra)

Классификация:

Функция установления соединения

Обработчик по умолчанию: Нет

Вспомогательные функции: iofunc_rename

Клиентская функция: rename

Сообщение: _IO_CONNECT, подтип _IO_CONNECT_RENAME

Структура данных:

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;

Описание: Выполняет операцию переименования, получив на вход первоначальное имя в элементе path и новое имя в поле path переданного параметра extra. Замечание по реализации: для первоначального имени задается имя пути (а не OCB) — это делается специально для случая переименования файла, который является жесткой связью к другому файлу. Если бы был задан OCB, две (или более) жестких связей к одному и тому же файлу различить было бы нельзя.

Данная функция будет вызываться только для тех двух имен файлов, которые принадлежат одной и той же файловой системе (то есть одному и тому же устройству). Поэтому в проверке случаев, в которых надо было бы возвращать EXDEV, нет никакой необходимости. Это ничуть не мешает вам возвращать EXDEV — например, если вы не хотите выполнять rename самостоятельно (например, операция переименования из одного каталога в другой может оказаться очень сложной). В случае возврата EXDEV командно-строковая утилита

mv

выполнит сначала

cp

, а потом

rm

(библиотечная функция rename этого не сделает — она просто установит errno в EXDEV).