Во время написания этого, для GLIBC 2.3.2 и ранее, GNU

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

ЗАМЕЧАНИЕ. Хотя POSIX определяет

statvfs

и

fstatvfs

, не все системы их поддерживают или поддерживают корректно. Многие системы (включая Linux, как вскоре будет описано), имеют свои собственные системные вызовы, предоставляющие сходную информацию. GNU

df

использует библиотечную процедуру для получения сведений о файловой системе; исходный файл для этой процедуры наполнен

#ifdef

для большого числа различных систем. Со временем ситуация с переносимостью должна улучшиться.

Битовые флаги

Обычной методикой, применимой во многих случаях, является использование набора значений флагов; когда флаг установлен (т.е. true), имеет место некоторый факт или применяется некоторое условие. Значения флагов определены либо через именованные константы

#define

, либо через перечисления. В данной главе API

nftw

(описанный далее) также использует флаги. Для поля

f_flag

структуры

struct statvfs

есть только два флага:

#define ST_RDONLY 1 /* файловая система только для чтения */

#define ST_NOSUID 2 /* setuid/setgid не разрешены */

Физически каждая именованная константа представляет различные позиции битов в значении

f_flag

. Логически каждое значение представляет отдельный бит информации о состоянии; т.е. некоторый факт или условие, которое является или не является истинным для данного конкретного экземпляра

struct statvfs

.

Флаги устанавливаются, проверяются и очищаются с помощью побитовых операторов С. Например,

statvfs

устанавливает эти флаги, используя побитовый оператор ИЛИ:

int statvfs(const char *path, struct statvfs *vfs) {

 /* заполнить большую часть *vfs */

 vfs->f_flag = 0; /* Убедиться, что начинается с нуля */

 if (файловая система только для чтения)

vfs->f_flag |= ST_RDONLY; /* Добавить флаг ST_RDONLY */

 if (файловая система запрещает setuid)

vfs->f_flag |= ST_NOSUID; /* Добавить флаг ST_NOSUID */

 /* оставшаяся часть процедуры */

}

Побитовый оператор И проверяет, установлен ли флаг, а сочетание побитовых операторов И и дополнения очищает флаг:

if ((vfs.f_flag & ST_RDONLY) != 0) /* True, если флаг ST_RDONLY */

 vfs.f_flag &= ~(ST_RDONLY|ST_NOSUID); /* Очистить оба флага */

Побитовые операторы отпугивают, если вы не использовали их ранее. Однако, только что показанный код примера представляет обычный стиль С. Тщательно изучите каждую операцию; возможно, нарисуйте себе несколько картин, показывающих работу этих операторов. Однажды разобравшись с ними, вы можете тренировать себя, распознавая эти операторы как высокоуровневые операции для управления значениями флагов вместо их трактовки как низкоуровневых манипуляций с битами.

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

unsigned long

дает возможность хранить по меньшей мере 32 отдельных бита информации. GLIBC (на момент написания) определяет 11 различных флагов для поля

f_flag

. [82] Если бы вы использовали для каждого флага отдельно поле

char

, это потребовало бы использования 11 байтов вместо четырех, используемых

unsigned long

. Если бы у вас было 32 флага, это были бы 32 байта вместо четырёх!

Системные вызовы

и специфичны для Linux. Их определения следующие:

Как и в случае с

и , две версии работают с именем файла или с дескриптором открытого файла соответственно, struct statfs выглядит следующим образом:

Поля аналогичны полям в

. По крайней мере в GLIBC 2.3.2 функции POSIX и являются оболочками вокруг и соответственно, копируя значения из одной разновидности структуры в другую.

Преимуществом использования

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

Есть два неудобства в использовании этих вызовов. Во-первых, они специфичны для Linux. Во-вторых, часть сведений из

отсутствует в , наиболее значительными из них являются флаги () и число доступных индексов (). (Поэтому Linux приходится находить опции монтирования из других источников, таких, как , и она «фабрикует» информацию для тех полей , для которых действительные сведения недоступны.)