Принадлежность и права доступа к символической ссылке игнорируются большинством операций (символические ссылки всегда создаются с предоставлением всех прав доступа). Вместо них при определении того, допустима ли какая-либо операция, используются принадлежность и права доступа к файлу, на который указывает ссылка. Принадлежность символической ссылки имеет значение, только когда сама ссылка удаляется или переименовывается в каталоге, для которого установлен закрепляющий бит прав доступа (см. подраздел 15.4.5).
Системные вызовы link() и unlink() создают и удаляют жесткие ссылки.
#include
int link(const char *
Возвращает 0 при успешном завершении или –1 при ошибке
Если системному вызову link() передать в аргументе oldpath имя пути к существующему файлу, этот системный вызов создаст новую ссылку, используя имя файла, указанное в аргументе newpath. Если файл newpath уже существует, он не перезаписывается; вместо этого результатом является ошибка EEXIST.
В Linux системный вызов link() не разыменовывает символические ссылки. Если аргумент oldpath является такой ссылкой, то по аргументу newpath создается новая жесткая ссылка на файл, соотнесенный с символической. (Другими словами, newpath также является символической ссылкой на тот же файл, с которым соотносится oldpath.) Данное поведение не соответствует стандарту SUSv3: в нем сказано, что все функции, выполняющие анализ имени пути, должны осуществлять разыменование символических ссылок, если не указано иное (а для системного вызова link() не указано исключение). Большинство других реализаций UNIX работает согласно указаниям стандарта SUSv3. Заметным исключением является ОС Solaris, которая по умолчанию обеспечивает такое же поведение, как и в Linux, но может также работать и в соответствии со стандартом SUSv3, если использовать соответствующие параметры компилятора. Такое несоответствие между реализациями приводит к заключению: в портируемых приложениях следует избегать передачи символической ссылки в аргумент oldpath.
Стандарт SUSv4 признает несоответствие между существующими реализациями и говорит о том, что выбор варианта обработки символических ссылок системным вызовом link() определяется реализацией. Стандарт SUSv4 добавляет также спецификацию системного вызова linkat(), выполняющего ту же задачу, что и link(), но имеющего аргумент flags, который можно использовать для управления разыменованием символических ссылок. Подробности см. в разделе 18.11.
#include
int unlink(const char *
Возвращает 0 при успешном завершении или –1 при ошибке
Системный вызов unlink() удаляет ссылку (имя файла) и, если это была последняя ссылка на данный файл, удаляет также и его. Если ссылка, указанная в аргументе pathname, не существует, системный вызов unlink() завершается ошибкой ENOENT.
Нельзя использовать системный вызов unlink() для удаления каталога; для этой задачи нужны системные вызовы rmdir() или remove(), которые мы рассмотрим в разделе 18.6.
В стандарте SUSv3 сказано, что, когда в аргументе pathname указан каталог, системный вызов unlink() должен завершаться ошибкой EPERM. Тем не менее в Linux системный вызов unlink() завершается в таком случае с ошибкой EISDIR. (Младший значащий бит явным образом допускает такое отклонение от стандарта SUSv3.) В портируемом приложении следует предусмотреть обработку каждой из этих ошибок.
Системный вызов unlink() не разыменовывает символические ссылки. Если аргумент pathname является такой ссылкой, то удаляется она сама, а не имя, на которое она указывает.
Помимо отслеживания счетчика ссылок для каждого индексного дескриптора ядро считает также открытые файловые дескрипторы данного файла (см. рис. 5.2). Если удалена последняя ссылка на файл, но какие-либо процессы удерживают открытыми дескрипторы, относящиеся к этому файлу, то он не будет фактически удален до тех пор, пока не будут закрыты все дескрипторы. Данная особенность удобна, поскольку позволяет разорвать связь с файлом, не заботясь о том, открыт ли он каким-либо другим процессом. (Тем не менее нельзя заново связать имя с открытым файлом, счетчик ссылок которого стал нулевым.) Кроме того, можно осуществить, например, такую хитрость: создать и открыть временный файл, немедленно разорвать связь с ним, а затем продолжить использовать его внутри программы, опираясь на тот факт, что данный файл будет удален, только когда мы закроем файловый дескриптор — либо явным образом, либо неявно, при выходе из программы. (Именно так работает функция tmpfile(), описанная в разделе 5.12.)
