.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson. .\" and Copyright (C) 2016 Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified Wed Jul 21 22:40:25 1993 by Rik Faith .\" Modified Sat Feb 18 15:27:48 1995 by Michael Haardt .\" Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer : .\" corrected description of effect on locks (thanks to .\" Tigran Aivazian ). .\" Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond .\" Modified 2000-07-22 by Nicolás Lichtmaier .\" added note about close(2) not guaranteeing that data is safe on close. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH CLOSE 2 "9 июня 2020 г." Linux "Руководство программиста Linux" .SH ИМЯ close \- закрывает файловый дескриптор .SH СИНТАКСИС .nf \fB#include \fP .PP \fBint close(int \fP\fIfd\fP\fB);\fP .fi .SH ОПИСАНИЕ Функция \fBclose\fP() закрывает файловый дескриптор, который после этого не ссылается ни на один и файл и может быть использован повторно. Все блокировки (см. \fBfcntl\fP(2)), связанные с соответствующим файлом и принадлежащие процессу, снимаются (независимо от того, какой файловый дескриптор был ли использован для установки блокировки). .PP Если \fIfd\fP является последней копией какого\-либо файлового дескриптора, ссылающегося на используемое описание открытого файла, (см. \fBopen\fP(2)), то ресурсы, связанные с описанием открытого файла, освобождаются; если файловый дескриптор был последней ссылкой на файл, удалённый с помощью \fBunlink\fP(2), то файл окончательно удаляется. .SH "ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ" При успешном выполнении функции \fBclose\fP() возвращается 0. В случае ошибки возвращается \-1, а \fIerrno\fP устанавливается в соответствующее значение. .SH ОШИБКИ .TP \fBEBADF\fP Значение \fIfd\fP не является допустимым открытым файловым дескриптором. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" Вызов \fBclose\fP() был прерван по сигналу; см. \fBsignal\fP(7). .TP \fBEIO\fP Произошла ошибка ввода\-вывода. .TP \fBENOSPC\fP, \fBEDQUOT\fP Для NFS об этих ошибках, обычно, не сообщается при первой записи, которая превысила доступное пространство памяти, а только в последующем \fBwrite\fP(), \fBfsync\fP(2) или \fBclose\fP(). .PP Смотрите в ЗАМЕЧАНИЯХ почему \fBclose\fP() нельзя вызывать снова после ошибки. .SH "СООТВЕТСТВИЕ СТАНДАРТАМ" .\" SVr4 documents an additional ENOLINK error condition. POSIX.1\-2001, POSIX.1\-2008, SVr4, 4.3BSD. .SH ЗАМЕЧАНИЯ Выполнение закрытия без ошибок не гарантирует, что данные были успешно записаны на диск, так как в ядре используется буферный кэш для отложенных записей. Как правило, файловые системы не записывают буферы при закрытии файла. Если требуется гарантировать физическую запись на используемый диск, то можно использовать \fBfsync\fP(2) (дальше всё будет зависеть от аппаратной составляющей диска). .PP .\" Флаг файлового дескриптора закрытие\-при\-exec можно использовать для гарантии того, что файловый дескриптор автоматически закроется при успешном выполнении \fBexecve\fP(2); подробности смотрите в \fBfcntl\fP(2). .SS "Multithreaded processes and close()" .\" Date: Tue, 4 Sep 2007 13:57:35 +0200 .\" From: Fredrik Noring .\" One such race involves signals and ERESTARTSYS. If a file descriptor .\" in use by a system call is closed and then reused by e.g. an .\" independent open() in some unrelated thread, before the original system .\" call has restarted after ERESTARTSYS, the original system call will .\" later restart with the reused file descriptor. This is most likely a .\" serious programming error. Вероятно неблагоразумно закрывать дескрипторы файла, в то время как они могут использоваться системными вызовами других нитей того же процесса. Так как файловый дескриптор может использоваться повторно, есть некоторые неясные условия возникновения гонок, которые могут вызвать непреднамеренные побочные эффекты. .PP Furthermore, consider the following scenario where two threads are performing operations on the same file descriptor: .IP 1. 3 One thread is blocked in an I/O system call on the file descriptor. For example, it is trying to \fBwrite\fP(2) to a pipe that is already full, or trying to \fBread\fP(2) from a stream socket which currently has no available data. .IP 2. Another thread closes the file descriptor. .PP The behavior in this situation varies across systems. On some systems, when the file descriptor is closed, the blocking system call returns immediately with an error. .PP .\" 'struct file' in kernel-speak .\" On Linux (and possibly some other systems), the behavior is different. the blocking I/O system call holds a reference to the underlying open file description, and this reference keeps the description open until the I/O system call completes. (See \fBopen\fP(2) for a discussion of open file descriptions.) Thus, the blocking system call in the first thread may successfully complete after the \fBclose\fP() in the second thread. .SS "Обработка ошибки, возвращённой close()" Аккуратный программист всегда проверяет возвращаемое \fBclose\fP() значение, так как очень вероятно, что об ошибках предыдущей операции \fBwrite\fP(2) будет сообщено только при последнем вызове \fBclose\fP(), который освобождает описание открытого файла. Невыполнение проверки возвращаемого значение при закрытии файла может привести к \fIнеучтённой\fP потере данных. Это особенно часто встречается с NFS и дисковыми квотами. .PP Однако заметим, что возвращаемая ошибка должна использоваться только для диагностики (т. е., предупредить приложение, что, возможно, есть незаконченные операции ввода\-вывода или произошла ошибка ввода\-вывода) или исправления (например, повторной записи файла или создания резервной копии). .PP .\" The file descriptor is released early in close(); .\" close() ==> __close_fd(): .\" __put_unused_fd() ==> __clear_open_fd() .\" return filp_close(file, files); .\" .\" The errors are returned by filp_close() after the FD has been .\" cleared for re-use. .\" filp_close() Повторный вызов \fBclose\fP() после получения ошибки делать не стоит, так как это может привести к закрытию повторно использованного файлового дескриптора другой нити. Это может произойти из\-за того, что ядро Linux \fIвсегда\fP освобождает файловый дескриптор в самом начале операции закрытия, делая его доступным для повторного использования; шаги, которые могут вернуть ошибку, такие как сброс данных в файловую систему или устройство, происходят только после операции закрытия. .PP .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. .\" Issue 8 Многие другие реализации поступают схожим образом и всегда закрывают файловый дескриптор (за исключением случая \fBEBADF\fP, означающего некорректный файловый дескриптор) даже, если они затем возвратят ошибку \fBclose\fP(). В POSIX.1 ничего не сказано на этот счёт, но есть планы узаконить такое поведение в следующем выпуске стандарта. .PP Аккуратный программист, который хочет узнать об ошибках ввода\-вывода, перед \fBclose\fP() вызовет \fBfsync\fP(2). .PP Ошибка \fBEINTR\fP является особым случаем. Про \fBEINTR\fP в POSIX.1\-2008 сказано: .PP .RS Если \fBclose\fP() прерван сигналом, который будет обработан, то вызов должен вернуть \-1, а \fIerrno\fP присвоить значение \fBEINTR\fP; при этом состояние \fIfildes\fP не определено. .RE .PP .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes further changes for EINTR .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=529 .\" .\" FIXME . .\" Review the following glibc bug later .\" https://sourceware.org/bugzilla/show_bug.cgi?id=14627 Этим допускается режим работы, действующий в Linux и многих других реализациях, где как и при других ошибках, которые может вернуть \fBclose\fP(), файловый дескриптор гарантированно закрывается. Однако, это также допускает и другой режим: реализация возвращает ошибку \fBEINTR\fP и оставляет файловый дескриптор открытым (согласно документации, так делает \fBclose\fP() в HP\-UX). Вызывающий должен позднее ещё раз вызвать \fBclose\fP() для закрытия файлового дескриптора, чтобы не допустить утечек файловых дескрипторов. Такое расхождение в поведении реализаций является сложным препятствием для переносимых приложений, так как во многих реализациях \fBclose\fP() не должен вызываться ещё раз после получения ошибки \fBEINTR\fP и, по крайней мере, в одной \fBclose\fP() нужно вызвать снова. Есть планы разгадать эту загадку в следующей большой версии стандарта POSIX.1. .SH "СМ. ТАКЖЕ" \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .SH ЗАМЕЧАНИЯ Эта страница является частью проекта Linux \fIman\-pages\fP версии 5.10. Описание проекта, информацию об ошибках и последнюю версию этой страницы можно найти по адресу \%https://www.kernel.org/doc/man\-pages/. .PP .SH ПЕРЕВОД Русский перевод этой страницы руководства был сделан Azamat Hackimov , Dmitriy S. Seregin , Dmitry Bolkhovskikh , Katrin Kutepova , Yuri Kozlov и Иван Павлов . .PP Этот перевод является бесплатной документацией; прочитайте .UR https://www.gnu.org/licenses/gpl-3.0.html Стандартную общественную лицензию GNU версии 3 .UE или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ. .PP Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на .MT man-pages-ru-talks@lists.sourceforge.net .ME .