Текст книги "Linux программирование в примерах"
Автор книги: Арнольд Роббинс
Жанры:
Программирование
,сообщить о нарушении
Текущая страница: 21 (всего у книги 55 страниц)
statfs() и fstatfs()Системные вызовы statfs() и fstatfs() специфичны для Linux. Их определения следующие:
#include
#include
int statfs(const char *path, struct statfs *buf);
int fstatfs(int fd, struct statfs *buf);
Как и в случае с statvfs() и fstatvfs(), две версии работают с именем файла или с дескриптором открытого файла соответственно, struct statfs выглядит следующим образом:
struct statfs {
long f_type; /* тип файловой системы */
long f_bsize; /* оптимальный размер блока */
long f_blocks; /* общее число блоков в файловой системе */
long f_bfree; /* число свободных блоков в ф.с. */
long f_bavail; /* свободные блоки, доступные пользователям */
long f_files; /* общее число индексов в файловой системе */
long f_ffree; /* свободных индексов в ф.с. */
fsid_t f_fsid; /* id файловой системы */
long f_namelen; /* максимальная длина имен файлов */
long f_spare[6]; /* запас для дальнейшего */
};
Поля аналогичны полям в struct statvfs. По крайней мере в GLIBC 2.3.2 функции POSIX statvfs() и fstatvfs() являются оболочками вокруг statfs() и fstatfs() соответственно, копируя значения из одной разновидности структуры в другую.
Преимуществом использования statfs() или fstatfs() является то, что они системные вызовы. Ядро возвращает информацию непосредственно. Поскольку нет поля f_flag с опциями монтирования, нет необходимости просматривать каждую смонтированную файловую систему для нахождения нужной. (Другими словами, для заполнения опций монтирования statfvs() должна проверить каждую смонтированную файловую систему, чтобы найти содержащую файл, имя которого содержится в path или fd. Функция statfs() не нуждается в этом, поскольку она не предоставляет сведений об опциях монтирования.)
Есть два неудобства в использовании этих вызовов. Во-первых, они специфичны для Linux. Во-вторых, часть сведений из struct statvfs отсутствует в struct statfs, наиболее значительными из них являются флаги (f_flag) и число доступных индексов (f_favail). (Поэтому statvfs() Linux приходится находить опции монтирования из других источников, таких, как /etc/mtab, и она «фабрикует» информацию для тех полей struct statvfs, для которых действительные сведения недоступны.)
Одно поле struct statfs заслуживает особого замечания. Это поле f_type, указывающее тип файловой системы. Значение является магическим числом файловой системы, извлеченной из суперблока. Справочная страница statfs(2) предоставляет список обычно используемых файловых систем и их магические числа, которые мы используем в ch08-statfs.c. (Увы, отдельного файла #include нет.)
1 /* ch08-statfs.с – демонстрация statfs Linux */
2
3 /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */
4
5 #include
6 #include
7 #include
8 #include
9 #include
10 #include
11
12 /* Определения взяты из справочной страницы для statfs(2): */
13 #define AFFS_SUPER_MAGIC 0xADFF
14 #define EFS_SUPER_MAGIC 0x00414A53
15 #define EXT_SUPER_MAGIC 0x137D
16 #define EXT2_OLD_SUPER_MAGIC 0xEF51
17 #define EXT2_SUPER_MAGIC 0xEF53
18 #define HPFS_SUPER_MAGIC 0xF995E849
19 #define ISOFS_SUPER_MAGIC 0x9660
20 #define MINIX_SUPER_MAGIC 0x137F /* оригинальный minix */
21 #define MINIX_SUPER_MAGIC2 0x138F /* 30-симв. minix */
22 #define MINIX2_SUPER_MAGIC 0x2468 /* minix V2 */
23 #define MINIX2_SUPER_MAGIC2 0x2478 /* minix V2, имена 30 симв. */
24 #define MSDOS_SUPER_MAGIC 0x4d44
25 #define NCP_SUPER_MAGIC 0x564c
26 #define NFS_SUPER_MAGIC 0x6969
27 #define PROC_SUPER_MAGIC 0x9fa0
28 #define SMB_SUPER_MAGIC 0x517B
29 #define XENIX_SUPER_MAGIC 0x012FF7B4
30 #define SYSV4_SUPER_MAGIC 0x012FF7B5
31 #define SYSV2_SUPER_MAGIC 0x012FF7B6
32 #define COH_SUPER_MAGIC 0x012FF7B7
33 #define UFS_MAGIC 0x00011954
34 #define XFS_SUPER_MAGIC 0x58465342
35 #define _XIAFS_SUPER_MAGIC 0x012FD16D
36
37 void process(const char *filename);
38 void do_statfs(const struct mntent *fs);
39
40 int errors = 0;
41 char *myname;
42
/* ...main() без изменений, process() почти идентична... */
85
86 /* type2str – преобразование типа fs в строку из statfs(2) */
87
88 const char *type2str(long type)
89 {
90 static struct fsname {
91 long type;
92 const char *name;
93 } table[] = {
94 { AFFS_SUPER_MAGIC, "AFFS" },
95 { COH_SUPER_MAGIC, "COH" },
96 { EXT2_OLD_SUPER_MAGIC, "OLD EXT2" },
97 { EXT2_SUPER_MAGIС, "EXT2" },
98 { HPFS_SUPER_MAGIC, "HPFS" },
99 { ISOFS_SUPER_MAGIC, "ISOFS" },
100 { MINIX2_SUPER_MAGIC, "MINIX V2" },
101 { MINIX2_SUPER_MAGIC2, "MINIX V2 30 char" },
102 { MINIX_SUPER_MAGIC, "MINIX" },
103 { MINIX_SUPER_MAGIC2, "MINIX 30 char" },
104 { MSDOS_SUPER_MAGIC, "MSDOS" },
105 { NCP_SUPER_MAGIС, "NCP" },
106 { NFS_SUPER_MAGIC, "NFS" },
107 { PROC_SUPER_MAGIC, "PROC" },
108 { SMB_SUPER_MAGIC, "SMB" },
109 { SYSV2_SUPER_MAGIC, "SYSV2" },
110 { SYSV4_SUPER_MAGIC, "SYSV4" },
111 { UFS_MAGIC, "UFS" },
112 { XENIX_SUPER_MAGIC, "XENIX" },
113 { _XIAFS_SUPER_MAGIC, "XIAFS" },
114 { 0, NULL },
115 };
116 static char unknown[100];
117 int i;
118
119 for (i = 0; table[i].type != 0; i++)
120 if (table[i].type == type)
121 return table[i].name;
122
123 sprintf(unknown, "unknown type: %#x", type);
124 return unknown;
125 }
126
127 /* do_statfs – Использовать statfs и вывести сведения */
128
129 void do_statfs(const struct mntent *fs)
130 {
131 struct statfs vfs;
132
133 if (fs->mnt_fsname[0] != '/') /* пропустить фиктивные файловые системы */
134 return;
135
136 if (statfs(fs->mnt_dir, &vfs) != 0) {
137 fprintf(stderr, "%s: %s: statfs failed: %sn",
138 myname, fs->mnt_dir, strerror(errno));
139 errors++;
140 return;
141 }
142
143 printf("%s, mounted on %s:n", fs->mnt_dir, fs->mnt_fsname);
144
145 printf("tf_type: %sn", type2str(vfs.f_type));
146 printf("tf_bsize: %ldn", vfs.f_bsize);
147 printf("tf_blocks: %ldn", vfs.f_blocks);
148 printf("tf_bfree: %ldn", vfs.f_bfree);
149 printf("tf_bavail: %ldn", vfs.f_bavail);
150 printf("tf_files: %ldn", vfs.f_files);
151 printf("tf_ffree: %ldn", vfs.f_ffree);
152 printf("tf_namelen: %ldn", vfs.f_namelen);
153 }
Чтобы сохранить место, мы опустили main(), которая не изменилась с представленной ранее другой программы, мы также опустили process (), которая теперь вызывает do_statfs() вместо do_statvfs().
Строки 13–35 содержат список магических чисел файловых систем из справочной страницы statfs(2). Хотя эти числа можно получить из заголовочных файлов исходного кода ядра, это трудно (мы пробовали), а показанному здесь способу представления следовать легче. Строки 86–125 определяют type2str(), которая преобразует магическое число в выводимую строку. Она осуществляет простой линейный поиск в таблице пар (значение, строка). В (маловероятном) случае, когда магическое число в таблице отсутствует, type2str() создает сообщение «неизвестный тип» и возвращает его (строки 123–124).
do_statfs() (строки 129–153) выводит сведения из struct statfs. Член f_fsid опущен, поскольку fsid_t является непрозрачным типом. Код прост; строка 145 использует type2str() для вывода типа файловой системы. Как для сходной программы, использующей statvfs(), эта функция игнорирует файловые системы, которые не расположены на локальных устройствах (строки 133–134). Вот вывод на нашей системе:
$ ch08-statfs /* Запуск программы */
/, mounted on /dev/hda2: /* Результаты для файловой системы ext2 */
f_type: ЕХТ2
f_bsize: 4096
f_blocks: 1549609
f_bfrее: 316664
f_bavail: 237946
f_files: 788704
f_ffree: 555483
f_namelen: 255
...
/win, mounted on /dev/hda1: /* Результаты для файловой с-мы vfat */
f_type: MSDOS
f_bsize: 4096
f_blocks: 2092383
f_bfree: 1391952
f_bavail: 1391952
f_files: 0
f_ffree: 0
f_namelen: 260
В заключение, использование statvfs() или statfs() в вашем собственном коде зависит от ваших потребностей. Как описано в предыдущем разделе, GNU df не использует statvfs() под GNU/Linux и в общем имеет тенденцию использовать уникальный для каждой Unix-системы системный вызов «получения сведений о файловой системе». Хотя это работает, это не очень привлекательно. С другой стороны, иногда у вас нет выбора: например, проблемы GLIBC, о которых мы упоминали выше. В этом случае нет безупречного решения.
Несколько системных вызовов и стандартных библиотечных функций дают возможность изменять текущий каталог и определять полный путь к текущему каталогу. Более сложные функции позволяют осуществлять произвольные действия с каждым объектом файловой системы в иерархии каталогов.
chdir() и fchdir()В разделе 1.2 «Модель процессов Linux/Unix» мы говорили:
Текущим каталогом является каталог, относительно которого отсчитываются относительные пути (те, которые не начинаются с
/). Это каталог, «в» котором вы находитесь, когда даете оболочке команду 'cd некоторое_место'.
У каждого процесса есть текущий рабочий каталог. Каждый новый процесс наследует свой текущий каталог от процесса, который его запустил (своего родителя). Две функции позволяют перейти в другой каталог:
#include
int chdir(const char *path); /* POSIX */
int fchdir(int fd); /* XSI */
Функция chdir() принимает строку с названием каталога, тогда как fchdir() ожидает дескриптор файла, который был открыт для каталога с помощью open().[83]83
На системах GNU/Linux и BSD для получения нижележащего дескриптора файла можно применить функцию dirfd() к указателю DIR*, см. справочную страницу GNU/Linux dirfd(3) – Примеч. автора.
[Закрыть] Обе возвращают 0 при успехе и -1 при ошибке (с errno, установленной соответствующим образом). Обычно, если open() для каталога завершается успешно, fchdir() также достигает цели, если кто-то не изменил права доступа к каталогу между вызовами, (fchdir() сравнительно новая функция; на старых системах Unix ее нет.)
Использование этих функций почти тривиально. Следующая программа, ch08-chdir.c, демонстрирует обе функции. Она демонстрирует также, что fchdir() может потерпеть неудачу, если права доступа открытого каталога не включают доступа на поиск (исполнение).
1 /* ch08-chdir.c – демонстрация chdir() и fchdir().
2 Для краткости проверка ошибок опущена */
3
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 int main(void)
11 {
12 int fd;
13 struct stat sbuf;
14
15 fd = open(".", O_RDONLY); /* открыть каталог для чтения */
16 fstat(fd, &sbuf); /* получить сведения, нужны начальные права доступа */
17 chdir(".."); /* 'cd ..' */
18 fchmod(fd, 0); /* отменить права доступа каталога */
19
20 if (fchdir(fd) < 0) /* попытаться выполнить 'cd' обратно, должно завершиться неудачей */
21 perror("fchdxr back");
22
23 fchmod(fd, sbuf.st_mode & 07777); /* восстановить первоначальные права доступа */
24 close(fd); /* все сделано */
25
26 return 0;
27 }
Строка 15 открывает текущий каталог. Строка 16 вызывает fstat() для открытого каталога, так что мы получаем копию его прав доступа. Строка 17 использует chdir() для перемещения на один уровень в иерархии файлов. Строка 18 выполняет грязную работу, отменяя все права доступа первоначального каталога.
Строки 20–21 пытаются перейти обратно в первоначальный каталог. Ожидается, что эта попытка будет безуспешной, поскольку текущие права доступа не позволяют это. Строка 23 восстанавливает первоначальные права доступа, 'sbuf.st_mode & 07777' получает младшие 12 битов прав доступа; это обычные 9 битов rwxrwxrwx и биты setuid, setgid и «липкий» бит, которые мы обсудим в главе 11 «Права доступа и ID пользователя и группы». Наконец, строка 24 заканчивает работу, закрывая открытый дескриптор файла. Вот что происходит при запуске программы.
$ ls -ld . /* Показать текущие права доступа */
drwxr-xr-x 2 arnold devel 4096 Sep 9 16:42 .
$ ch08-chdir /* Запустить программу */
fchdir back: Permission denied /* Ожидаемая неудача */
$ ls -ld . /* Снова посмотреть на права доступа */
drwxr-xr-x 2 arnold devel 4096 Sep 9 16:42 /* Все восстановлено как раньше */
getcwd()Названная должным образом функция getcwd() получает абсолютный путь текущего рабочего каталога.
#include
char *getcwd(char *buf, size_t size);
Функция заносит в buf путь; ожидается, что размер buf равен size байтам. При успешном завершении функция возвращает свой первый аргумент. В противном случае, если требуется более size байтов, она возвращает NULL и устанавливает в errno ЕRANGE. Смысл в том, что если случится ERANGE, следует попытаться выделить буфер большего размера (с помощью malloc() или realloc()) и попытаться снова.
Если любой из компонентов каталога, ведущих к текущему каталогу, не допускает чтения или поиска, getcwd() может завершиться неудачей, а errno будет установлен в EACCESS. Следующая простая программа демонстрирует ее использование:
/* ch08-getcwd.c – демонстрация getcwd().
Проверка ошибок для краткости опущена */
#include
#include
#include
#include
#include
int main(void) {
char buf[PATH_MAX];
char *cp;
cp = getcwd(buf, sizeof(buf));
printf("Current dir: %sn", buf);
printf("Changing to ..n");
chdir(".."); /* 'cd ..' */
cp = getcwd(buf, sizeof(buf));
printf("Current dir is now: %sn", buf);
return 0;
}
Эта простая программа выводит текущий каталог, переходит в родительский каталог, затем выводит новый текущий каталог. (Переменная cp здесь на самом деле не нужна, но в реальной программе она была бы использована для проверки ошибок). При запуске программа создает следующий вывод:
$ ch08-getcwd
Current dir: /home/arnold/work/prenhall/progex/code/ch08
Changing to ..
Current dir is now: /home/arnold/work/prenhall/progex/code
Формально, если аргумент buf равен NULL, поведение getcwd() не определено. В данном случае версия GLIBC getcwd() вызовет malloc() за вас, выделяя буфер с размером size. Идя даже дальше, если size равен 0, выделяется «достаточно большой» буфер для вмещения возвращенного имени пути. В любом случае вы должны вызвать для возвращенного указателя free() после завершения работы с буфером.
Поведение GLIBC полезно, но не переносимо. Для кода, который должен работать на разных платформах, вы можете написать замещающую функцию, которая предоставляет те же самые возможности, в то же время заставив ее непосредственно вызывать getcwd() на системе с GLIBC.
Системы GNU/Linux предоставляют файл /proc/self/cwd. Этот файл является символической ссылкой на текущий каталог:
$ cd /tmp /* Сменить каталог */
$ ls -l /рroc/self/cwd /* Посмотреть на файл */
lrwxrwxrwx 1 arnold devel 0 Sep 9 17:29 /proc/self/cwd -> /tmp
$ cd /* Перейти в домашний каталог */
$ ls -l /proc/self/cwd /* Снова посмотреть на него */
lrwxrwxrwx 1 arnold devel 0 Sep 9 17:30 /proc/self/cwd -> /home/arnold
Это удобно на уровне оболочки, но представляет проблему на уровне программирования. В частности, размер файла равен нулю! (Это потому, что это файл в /proc, который продуцирует ядро; это не настоящий файл, находящийся на диске.)
Почему нулевой размер является проблемой? Если вы помните из раздела 5.4.5 «Работа с символическими ссылками», lstat() для символической ссылки возвращает в поле st_size структуры struct stat число символов в имени связанного файла. Это число может затем использоваться для выделения буфера соответствующего размера для использования с readlink(). Здесь это не будет работать, поскольку размер равен нулю. Вам придется использовать (или выделять) буфер, который, как вы полагаете, достаточно большой. Однако, поскольку readlink() не выдает символов больше, чем вы предоставили места, невозможно сказать, достаточен буфер или нет; readlink() не завершается неудачей, когда недостаточно места. (См. в разделе 5.4.5 «Работа с символическими ссылками» функцию Coreutils xreadlink(), которая решает проблему.)
В дополнение к getcwd() GLIBC имеет несколько других непереносимых процедур. Они избавляют вас от хлопот по управлению буферами и обеспечивают совместимость со старыми системами BSD. Подробности см в getcwd(3).
nftw()Обычной задачей программирования является обработка целых иерархий каталогов: выполнение действий над каждым файлом и каждым каталогом и подкаталогом в целостном дереве. Рассмотрите, например, команду du, которая выводит сведения об использовании диска, 'chown -R', которая рекурсивно изменяет владельцев, или программу find, которая находит файлы, подходящие по определенным критериям.
На данный момент вы знаете достаточно, чтобы написать собственный код для открывания и чтения каталогов вручную, вызова stat() (или lstat()) для каждого элемента и рекурсивной обработки подкаталогов. Однако, такой код трудно сделать правильным; можно выйти за пределы дескрипторов файлов, если вы будете оставлять родительские каталоги открытыми при обработке подкаталогов; нужно решить, обрабатывать ли символические ссылки как таковые или как файлы, на которые они указывают; нужно суметь справиться с каталогами, которые недоступны для чтения или поиска и т.д. Также трудно писать один и тот же код снова и снова, когда он требуется в нескольких приложениях.
nftw()Чтобы избавиться от проблем, System V предложила функцию ftw() («file tree walk» – обход дерева файлов), ftw() осуществляла всю работу по «прохождению» дерева (иерархии) файлов. Вы предоставляете ей указатель на функцию, и она вызывает эту функцию для каждого объекта файла, с которым сталкивается. Ваша функция должна затем обработать каждый объект файловой системы, как считает нужным.
Со временем стало ясно, что интерфейс ftw() не вполне выполнял свою работу;[84]84
POSIX стандартизировал ftw() для поддержки существующего кода, а GNU/Linux b коммерческие системы Unix продолжают её поддерживать. Однако, поскольку она недостаточно функциональна, мы не будем больше ее обсуждать. Если интересуетесь, см. ftw(3). – Примеч. автора.
[Закрыть] например, первоначально он не поддерживал символические ссылки. По этим причинам к X/Open Portability Guide, который теперь является частью POSIX, была добавлена nftw() («new (новая) ftw()» [важно]). Вот прототип:
#include
int nftw(const char *dir, /* Отправная точка */
int (*fn)(const char *file, /* Указатель функции на */
const struct stat *sb, /* функцию из четырех аргументов */
int flag, struct FTW *s),
int depth, int flags); /* Максимум открытых fds, флаги */
А вот аргументы:
const char *dir
Строка с именем отправной точки иерархии для обработки.
int (*fn)(const char *file, const struct stat *sb, int flag, struct FTW *s)
Указатель на функцию с данными аргументами. Эта функция вызывается для каждого объекта в иерархии. Подробности ниже.
int depth
Этот аргумент назван неверно. Чтобы избежать выхода за пределы дескрипторов файлов, nftw() держит открытыми не более, чем depth одновременно открытых каталогов. Это не препятствует обработке nftw() иерархий, которые глубже уровня depth, но меньшие значения depth означают, что nftw() придется делать больше работы.
flags
Набор флагов, объединяемых побитовым ИЛИ, которые указывают, как nftw() должна обрабатывать иерархию.
Интерфейс nftw() имеет два отдельных набора флагов. Одни набор контролирует саму nftw() (аргумент flags функции nftw()). Другой набор передается предоставленной пользователем функции, которую вызывает nftw() (аргумент flags для (*fn)()). Однако, интерфейс запутывает, поскольку имена обоих наборов флагов начинаются с префикса 'FTW_'. Мы постараемся сделать все, чтобы это прояснить по ходу дела. В табл. 8.3 представлены флаги, которые контролируют nftw().
Таблица 8.3. Управляющие флаги для nftw()
FTW_CHDIR | При установке перед открытием каждого из каталогов сначала осуществляется переход в него. Это действие более эффективно, но вызывающее приложение должно быть готово оказаться в другом каталоге, когда nftw() завершится |
FTW_DEPTH | При установке осуществляется «сначала глубокий поиск». Это означает, что все файлы и подкаталоги обрабатываются до того, как будет обработан сам каталог |
FTW_MOUNT | При установке остается в той же самой смонтированной файловой системе. Это более специализированная опция |
FTW_PHYS | При установке не следует по символическим ссылкам |
FTW_CHDIR предоставляет большую эффективность; при обработке глубоких иерархий файлов ядру не приходится обрабатывать снова и снова полные пути имен при осуществлении stat() или открытии каталога. Экономия времени для больших иерархий может быть вполне ощутимой.[85]85
У некоторых старых версий GLIBC были проблемы с FTW_CHDIR. Это не относится к GLIBC 2.3.2 и более поздним, и маловероятно, что вы столкнетесь с проблемами – Примеч. автора.
[Закрыть]
FTW_DEPTH может быть, а может и не быть тем, что вам нужно; для некоторых приложений это безусловно справедливо. Рассмотрите 'chmod -R u-rx .'. Эта команда удаляет права чтения и исполнения для владельца для всех файлов и подкаталогов в текущем каталоге. Если это изменение прав доступа применено к каталогу до того, как оно применено к содержимому каталога, любые последующие попытки обработки содержимого потерпят неудачу! Поэтому команда должна применяться к каталогу после обработки его содержимого.[86]86
Мы не знаем, почему кому-нибудь может понадобиться делать такое изменение, но философия «что вы просили, то и получили» применяется и здесь! – Примеч. автора.
[Закрыть] Справочная страница GNU/Linux nftw(3) отмечает для FTW_PHYS, что «это то, что вам нужно». Это позволяет вам обрабатывать сами символические ссылки, что обычно бывает нужно (Рассмотрите du, она должна подсчитывать занимаемое ссылками пространство отдельно от связанных с ними файлов.)
