Для большинства приложений вероятность того, что данные в буферном кэше могут быть нечаянно потеряны, довольно низка. Однако, для некоторых приложений любой такой шанс неприемлем. Поэтому в системе Unix было введено понятие синхронного ввода/вывода, при котором программе гарантируется, что по возвращении из системного вызова данные безопасно записаны на физическое устройство хранения.
Флаг
O_DSYNC
гарантирует целостность данных; данные и любая другая информация, которую операционная система должна найти, записываются на диск до возвращения
write
. Однако, вспомогательные данные, такие, как время модификации или доступа к файлу, могут
быть не записаны на диск. Флаг
O_SYNC
требует, чтобы эти данные также были записаны на диск до возвращения
write
. (Здесь тоже нет бесплатного обеда; синхронные записи могут серьезно повлиять на производительность программы, заметно ее снизив.)
Флаг
O_RSYNC
предназначен для чтения данных: если
read
находит данные в буферном кэше, которые были назначены для записи на диск, функция не вернет эти данные до тех пор, пока они не будут записаны. Два других флага влияют на это: в частности,
O_SYNC
заставит
read
ждать, пока не будут также записаны и вспомогательные данные.
ЗАМЕЧАНИЕ. Что касается ядра версии 2.4, Linux рассматривает все три флага одинаково со значением флага
O_SYNC
. Более того, Linux определяет дополнительные флаги, которые специфичны для Linux и предназначены для специального использования. Дополнительные подробности см. в справочной странице GNU/Linux для open(2).
4.7. Форсирование записи данных на диск
Ранее мы описали флаги
O_DSYNC
,
O_RSYNC
и
O_SYNC
для
open
. Мы отметили, что использование этих флагов может замедлить программу, поскольку
write
не возвращается до тех пор, пока все данные не будут записаны на физический носитель.
Со слегка более высоким уровнем риска мы можем сами испечь свое пирожное и съесть его. Это осуществляется путем открытия файла без указания флагов
O_xSYNC
, но с последующим использованием одного из следующих двух системных вызовов в любой момент, когда это необходимо для безопасного перемещения данных на физический носитель:
#include <unistd.h>
int fsync(int fd); /* POSIX FSC */
int fdatasync(int fd); /* POSIX SIO */
Системный вызов
fdatasync
подобен
O_DSYNC
: он форсирует запись данных на конечное физическое устройство. Системный вызов
fsync
подобен
O_SYNC
, форсируя запись на физическое устройство не только данных файла, но и вспомогательных данных. Вызов
fsync
более переносим; он существовал в мире Unix в течение более продолжительного времени, и вероятность его наличия среди широкого ряда систем больше.
Можно использовать эти вызовы с указателями файлов
<stdio.h>
, вызвав сначала
fflush
, а затем
fileno
для получения дескриптора нижележащего файла. Вот функция
fpsync
, которая может использоваться для заключения обеих операций в один вызов. Она возвращает в случае успеха 0:
в расширении «Синхронизированный ввод и вывод». Тем не менее, можно без проблем использовать их в системе GNU/Linux
4.8. Установка длины файла
Два системных вызова позволяют настраивать размер файла:
#include <unistd.h>
#include <sys/types.h>
int truncate(const char *path, off_t length); /* XSI */
int ftruncate(int fd, off_t length); /* POSIX */
Как должно быть очевидно из параметров,
truncate
принимает аргумент имени файла, тогда как
ftruncate
работает с дескриптором открытого файла. (Обычным является соглашение по именованию пар системных вызовов
xxx
и
fxxxx
, работающих с именами файлов и дескрипторами файлов. Мы увидим несколько примеров в данной и последующих главах.) В обоих случаях аргумент
length
является новым размером файла.
Этот системный вызов происходит от 4.2 BSD Unix, и на ранних системах мог использоваться лишь для сокращения длины файла, отсюда и название. (Он был создан, чтобы облегчить реализацию операции урезания в Фортране.) На современных системах, включая Linux, имя является неправильным, поскольку с помощью этих вызовов можно также увеличить, а не только сократить длину файла. (Однако, POSIX указывает, что возможность увеличения размера файла относится к расширению XSI.)
Для этих вызовов сокращаемый файл должен иметь разрешение на запись (для
truncate
), или должен быть открыт для записи (для
ftruncate
). Если файл сокращается, все данные после нового конца файла теряются. (Поэтому вы не можете сократить файл, снова удлинить его и найти там первоначальные данные.) Если файл-расширен, как в случае записи данных после
lseek
, данные между старым концом файла и новым концом файла читаются как нули.
Эти вызовы сильно отличаются от '
open(file, ... | O_TRUNC, mode)
', который полностью урезает файл, отбрасывая все его данные. Эти же вызовы просто устанавливают абсолютную длину файла в данное значение.
Эти функции довольно специализированы; они используются лишь четыре раза во всем коде GNU Coreutils. Мы представляем пример использования
ftruncate
в разделе 5.5.3 «Изменение отметок времени:
utime
».
4.9. Резюме
• Когда системный вызов завершается неудачей, он обычно возвращает -1, а в глобальной переменной errno устанавливается предопределенное значение, указывающее на проблему. Для сообщений об ошибках могут использоваться функции
perror
и
strerror
.
• Доступ к файлам осуществляется через небольшие целые, которые называются дескрипторами. Дескрипторы файлов для стандартного ввода, стандартного вывода и стандартной ошибки наследуются от родительского процесса программы. Другие получаются через
open
или
creat
. Для их закрытия используется
close
, a
getdtablesize
возвращает разрешенное максимальное число открытых файлов. Значение
umask
(устанавливаемое с помощью
umask
) влияет на права доступа, получаемые новыми файлами при создании с помощью