Разработка приложений в среде Linux. Второе издание - Майкл Джонсон

73:   return 1;

74:  }

75:

76:  return 0;

77: }

11.4.2. Создание жестких ссылок

Когда множество имен файлов в файловой системе ссылаются на единственный inode, такие файлы называют жесткими ссылками (hard links) на него. Все эти имена должны располагаться на одном физическом носителе (обычно это значит, что они должны быть на одном устройстве). Когда файл имеет множество жестких ссылок, все они равны — нет способа узнать, с каким именем первоначально был создан файл. Одно из преимуществ такой модели заключается в том, что удаление одной жесткой ссылки не удаляет файл с устройства — он остается до тех пор, пока все ссылки на него не будут удалены. Системный вызов link() связывает новое имя файла с существующим inode.

#include <unistd.h>

int link(const char *origpath, const char *newpath);

Параметр origpath ссылается на существующее путевое имя, a newpath представляет собой путь для новой жесткой ссылки. Любой пользователь может создавать ссылку на файл, к которому у него есть доступ по чтению, до тех пор, пока он имеет право записи в каталоге, в котором ссылка создается, и право выполнения в каталоге, в котором находится origpath. Только пользователь root имеет право создавать жесткие ссылки на каталоги, но поступать так — обычно плохая идея, поскольку большинство файловых систем и некоторые утилиты не работают с ними достаточно хорошо — они полностью их отвергают.

11.4.3. Использование символических ссылок

Символические ссылки — это более гибкий тип ссылок, чем жесткие, но они не дают равноправного доступа к файлу, как это делают жесткие. В то время как жесткие ссылки разделяют один и тот же inode, символические ссылки просто указывают на другие имена файлов. Если файл, на который указывает символическая ссылка, удаляется, то она указывает на несуществующий файл, что приводит к появлению висячих ссылок. Использование символических ссылок между подкаталогами — обычная практика, и они могут также пересекать границы физических систем, чего не могут жесткие ссылки.

Почти все системные вызовы, которые обращаются к файлам по путевым именам, автоматически следуют по символическим ссылкам для поиска правильного inode. Ниже перечислены вызовы, которые не следуют по символическим ссылкам.

• chown()

• lstat()

• readlink()

• rename()

• unlink()

Символически ссылки создаются почти так же, как жесткие, но при этом используется системный вызов symlink().

#include <unistd.h>

int symlink(const char *origpath, const char *newpath);

Если вызов успешен, создается файл newpath как символическая ссылка, указывающая на oldpath (часто говорят, что newpath содержит в качестве своего значения oldpath).

Поиск значения символической ссылки немного сложнее.

#include <unistd.h>

int readlink(const char *pathname, char *buf, size_t bufsiz);

Буфер, на который указывает buf, наполняется содержимым символической ссылки pathname до тех пор, пока хватает длины buf, указанной в bufsize в байтах. Обычно константы PATH_MAX применяется в качестве размера буфера, поскольку она должна быть достаточно большой, чтобы уместить содержимое любой символической ссылки[49]. Одна странность функции readlink() связана с тем, что она не завершает строку, которую записывает в buf, символом '', поэтому buf не содержит корректную строку С, даже если readlink() выполняется успешно. Вместо этого она возвращает количество байт, записанных в buf в случае успеха и -1 — при неудаче. Из-за этой особенности код, использующий readlink(), часто выглядит так, как показано ниже.

char buf[PATH_MAX + 1];

int bytes;

if ( (bytes = readlink (pathname, buf, sizeof (buf) - 1)) < 0) {

 perror("ошибка в readlink");

} else {

 buf[bytes]= '';

}

11.4.4. Удаление файлов

Удаление файла — это удаление указателя на его inode и удаление содержимого файла, если не остается ни одой жесткой ссылки на него. Если любой процесс держит файл открытым, то inode этого файла предохраняется до тех пор, пока финальный процесс не закроет его, после чего и inode, и содержимое файла уничтожаются. Поскольку нет способа принудительно удалить файл немедленно, эта операция называется разъединением (unlinking) файла, поскольку она удаляет связь между именем файла и inode.

#include <unistd.h>

int unlink(char *pathname);

11.4.5. Переименование файлов

Имя файла может быть изменено на любое другое до тех пор, пока оба имени относятся к одному и тому же физическому носителю (это то же ограничение, что и касается создания жестких ссылок). Если новое имя уже ссылается на файл, то такое имя разъединяется перед тем, как произойдет переименование. Атомарность системного вызова rename() гарантируется. Другие процессы в системе всегда видят существование файла под тем или иным именем, но не под обеими сразу. Поскольку открытые файлы не связаны с именами (а только с inode), то переименование файла, который открыт в других процессах, никак не влияет на их работу. Ниже показано, как выглядит системный вызов для переименования файлов.

#include <unistd.h>

int rename(const char *oldpath, const char *newpath);

После вызова файл, на который ссылалось имя oldpath, получает ссылку newpath вместо oldpath.

11.5. Манипуляции файловыми дескрипторами

Почти все связанные с файлами системные вызовы, о которых мы говорили, за исключением lseek(), манипулируют inode файлов, что позволяет разделять их результаты между процессами, в которых этот файл открыт. Есть несколько системных вызовов, которые вместо этого имеют дело с самим файловыми дескрипторами. Системный вызов fcntl() может использоваться для множества манипуляций с файловыми дескрипторами. fcntl() выглядит следующим образом.

#include <unistd.h>

int fcntl (int fd, int command, long arg);

Для многих команд arg не используется. Ниже мы обсудим большую часть применений fcntl(). Этот вызов используется для блокировки файлов, аренды файлов, неблокирующего ввода-вывода, который рассматривается в главе 13, а также уведомления об изменениях каталогов, представленного в главе 14.

11.5.1. Изменение режима доступа к открытому файлу

Режим добавления (указываемый флагом O_APPEND при открытии файла) и неблокирующий режим (флаг O_NONBLOCK), могут быть включены и отключены уже после того, как файл был открыт, с помощью команды F_SETFL в fcntl(). Параметр arg при этом должен содержать флаги, которые нужно установить — если какой-то из флагов не указан для fd, он отключается.

F_GETFL можно использовать для запроса текущих установленных флагов файла. Это возвращает все флаги, включая режим чтения/записи для открытого файла. F_SETFL позволяет только устанавливать упомянутые выше флаги — любые другие флаги, представленные в аргументе arg, игнорируются.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_RDONLY);

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

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) | O_APPEND);

Следует отметить, что это предохраняет установку O_NONBLOCK. Отключение режима добавления выглядит похоже.

fcntl(fd, F_SETFL, fcntl(fd, F_GETFL, 0) & ~O_APPEND);

11.5.2. Модификация флага "закрыть при выполнении"

Во время системного вызова exec() дескрипторы файлов обычно остаются открытыми для использования в новых программах. В некоторых случаях может потребоваться, чтобы файлы закрывались, когда вызывается exec(). Вместо закрытия их вручную вы можете попросить систему закрыть соответствующий файловый дескриптор при вызове exec() с помощью команд F_GETFD и F_SETFD в fcntl(). Если флаг "закрыть при выполнении" (close-on-exec) установлен, когда применяется F_GETFD, возвращается ненулевое значение, в противном случае возвращается ноль. Флаг "закрыть при выполнении" устанавливается командой F_SETFD; он отключается, если arg равно 0, в противном случае он включается.

Ниже показано, как можно заставить fd закрываться, когда процесс вызывает exec().

fcntl(fd, F_SETFD, 1);

11.5.3. Дублирование файловых дескрипторов

Иногда процессам требуется создать новый файловый дескриптор, который ссылается на ранее открытый файл. Командные оболочки используют эту функциональность для перенаправления стандартного ввода, вывода и потока ошибок по запросу пользователя. Если процессу не важно, какой файловый дескриптор будет использован для новой ссылки, он должен использовать dup().