Текст книги "Linux программирование в примерах"

322    ep->ln.lname[j] = dentry.d_name[j];

323  }

324  fclose(dirf);

325 }

Строки 297–325 определяют функцию readdir(), чья работа заключается в чтении содержимого каталогов, указанных в командной строке.

Строки 304–307 открывают каталог для чтения, завершая функцию, если fopen() возвращает ошибку. Строка 308 инициализирует глобальную переменную tblocks нулем. Ранее (строки 153–154) это использовалось для вывода общего числа блоков, использованных файлами в каталоге.

Строки 309–323 являются циклом, который читает элементы каталога и добавляет их к массиву flist. Строки 310–311 читают один элемент, выходя из цикла в конце файла.

Строки 312–315 пропускают неинтересные элементы. Если номер индекса равен нулю, этот слот не используется. В противном случае, если не был указан -а и имя файла является '.' или '..', оно пропускается.

Строки 316–318 вызывают gstat() с полным именем файла и вторым аргументом, равным false, указывающим, что он не из командной строки. gstat() обновляет глобальный указатель lastp и массив flist. Возвращаемое значение NULL обозначает какую-нибудь разновидность ошибки.

Строки 319–322 сохраняют номер индекса и имя в struct lbuf. Если ep->lnum возвращается из gstat() установленным в -1, это означает, что операция stat() с файлом завершилась неудачей. Наконец, строка 324 закрывает каталог.

Следующая функция, gstat() (строки 327–398), является центральной функцией для получения и сохранения сведений о файле.

327 struct lbuf * /* struct lbuf *gstat(char *file, int argfl) */

328 gstat(file, argfl)

329 char *file;

330 {

331  extern char *malloc();

332  struct stat statb;

333  register struct lbuf *rep;

334  static int nomocore;

335

336  if (nomocore) /* Ранее была нехватка памяти */

337   return(NULL);

338  rep = (struct lbuf*)malloc(sizeof(struct lbuf));

339  if (rep==NULL) {

340   fprintf(stderr, "ls: out of memoryn");

341   nomocore = 1;

342   return(NULL);

343  }

344  if (lastp >= &flist[NFILES]) { /* Проверить, не дано ли слишком много файлов */

345   static int msg;

346   lastp–;

347   if (msg==0) {

348    fprintf(stderr, "ls: too many filesn");

349    msg++;

350   }

351  }

352  *lastp++ = rep; /* Заполнить сведения */

353  rep->lflags = 0;

354  rep->lnum = 0;

355  rep->ltype = '-'; /* Тип файла по умолчанию */

Статическая переменная nomocore [важно] указывает, что malloc() при предыдущем вызове завершилась неудачей. Поскольку она статическая, она автоматически инициализируется 0 (т.е. false). Если на входе она равна true, gstat() просто возвращает NULL. В противном случае, если malloc() завершается неудачей, ls выводит сообщение об ошибке, устанавливает в nomocore true и возвращает NULL (строки 334–343).

Строки 344–351 гарантируют, что в массиве flist все еще остается место. Если нет, ls выдает сообщение (но лишь однажды; заметьте использование статической переменной msg), а затем повторно использует последний слот flist.

Строка 352 заставляет слот lastp указывать на новую struct lbuf (rep). Это также обновляет lastp, который используется для сортировки в main() (строки 142 и 152). Строки 353–355 устанавливают значения по умолчанию для полей флагов, номеров индексов и типов в struct lbuf.

356  if (argfl || statreq) {

357   if (stat(file, &statb)<0) { /* stat() завершилась неудачей */

358    printf("%s not foundn", file);

359    statb.st_ino = -1;

360    statb.st_size = 0;

361    statb.st_mode = 0;

362    if (argfl) {

363     lastp–;

364     return(0);

365    }

366   }

367   rep->lnum = statb.st_ino; /* stat() OK, копировать сведения */

368   rep->lsize = statb.st_size;

369   switch(statb.st_mode & S_IFMT) {

370

371   case S_IFDIR:

372    rep->ltype = 'd';

373    break;

374

375   case S_IFBLK:

376    rep->ltype = 'b';

377    rep->lsize = statb.st_rdev;

378    break;

379

380   case S_IFCHR:

381    rep->ltype = 'c';

382    rep->lsize = statb.st_rdfev;

383    break;

384   }

385   rep->lflags = statb.st_mode & ~S_IFMT;

386   rep->luid = statb.st_uid;

387   rep->lgid = statb.st_gid;

388   rep->lnl = statb.st_nlink;

389   if (uflg)

390    rep->lmtime = statb.st_atime;

391   else if (cflg)

392    rep->lmtime = statb.st_ctime;

393   else

394    rep->lmtime = statb.st_mtime;

395   tblocks += nblock(statb.st_size);

396  }

397  return(rep);

398 }

Строки 356–396 обрабатывают вызов stat(). Если это аргумент командной строки или если statreq установлен в true благодаря опции, код заполняет struct lbuf следующим образом:

• Строки 357–366: вызывают stat(), при ее неудаче выводится сообщение об ошибке с установкой соответствующих значений, затем возвращается NULL (выраженный в виде 0).

• Строки 367–368: устанавливают в struct stat поля номера индекса и размера, если вызов stat() был успешным.

• Строки 369–384: обрабатывают особые случаи каталогов, блочных и символьных устройств. Во всех случаях код обновляет поле ltype. Для устройств значение lsize замещается значением st_rdev.

• Строки 385–388. заполняются поля lflags, luid, lgid и lnl из соответствующих полей в struct stat. Строка 385 удаляет биты типа файла, оставляя 12 битов прав доступа (на чтение/запись/исполнение для владельца/группы/остальных, а также setuid, setgid и save-text).

• Строки 389–394: основываясь на опциях командной строки, используют одно из трех полей времени в struct stat для поля lmtime в struct lbuf.

• Строка 395: обновляет глобальную переменную tblocks числом блоков в файле.

400 compar(pp1, pp2) /* int compar(struct lbuf **pp1, */

401 struct lbuf **pp1, **pp2; /* struct lbuf **pp2) */

402 {

403  register struct lbuf *p1, *p2;

404

405  p1 = *pp1;

406  p2 = *pp2;

407  if (dflg==0) {

408   if (p1->lflags&ISARG && p1->ltype=='d') {

409    if (!(p2->lflags&ISARG && p2->ltype=='d'))

410     return(1);

411   } else {

412    if (p2->lflags&ISARG && p2->ltype=='d')

413     return(-1);

414   }

415  }

416  if (tflg) {

417   if(p2->lmtime == p1->lmtime)

418    return(0);

419   if (p2->lmtime > p1->lmtime)

420    return(rflg);

421   return(-rflg);

422  }

423  return(rflg * strcmp(p1->lflags&ISARG ? p1->ln.namep : p1->ln.lname,

424   p2->lflags&ISARG ? p2->ln.namep : p2->ln.lname));

425 }

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

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

Наконец, переменная rflg помогает реализовать опцию -r, которая меняет порядок сортировки. Она инициализируется 1 (строка 30). Если -r используется, rflg устанавливается в -1 (строки 89–91).

Следующий псевдокод описывает логику compar(); номера строк на левой границе соответствуют номерам строк ls.c:

407 if ls должна прочесть каталоги # dflg == 0

408  if p1 аргумент командной строки и p1 каталог

409   if p2 не аргумент командной строки и не каталог

410    return 1 # первый идет после второго

      else

       перейти на тест времени

411  else

      # p1 не каталог командной строки

412   if p2 аргумент командной строки и каталог

413    return -1 # первый идет перед вторым

      else

       перейти на тест времени

416 if сортировка основана на времени # tflg равно true

     # сравнить времена:

417  if время p2 равно времени p1

418   return 0

419  if время p2 > времени p1

420   return значение rflg (положительное или отрицательное)

     # время p2 < времени p1

421  return противоположное rflg значение (положительное или отрицательное)

423 Умножить rflg на результат strcmp()

424 для двух имен и вернуть результат

Аргументы strcmp() в строках 423–424 выглядят сбивающими с толку. В зависимости от того, было ли имя файла указано в командной строке или было прочитано из каталога, должны использоваться различные члены объединения ln в struct lbuf.

• V7 ls является сравнительно небольшой программой, хотя она затрагивает многие фундаментальные аспекты программирования Unix – файловый ввод-вывод, вспомогательные данные файлов, содержание каталогов, пользователи и группы, значения времени и даты, сортировку и динамическое управление памятью.

• Наиболее примечательным внешним различием между V7 ls и современной ls является трактовка опций -а и -l. У версии V7 значительно меньше опций, чем у современных версий; заметным недостатком является отсутствие рекурсивной опции -R.

• Управление flist является чистым способом использования ограниченной памяти архитектуры PDP-11, предоставляя в то же время как можно больше сведений, struct lbuf хорошо извлекает нужные сведения из struct stat; это значительно упрощает код. Код для вывода девяти битов доступа компактен и элегантен.

• Некоторые части ls используют удивительно маленькие лимиты, такие, как верхняя граница числа файлов в 1024 или размер буфера в makename() в 100.

1. Рассмотрите функцию getname(). Что случится, если запрошенный ID равен 256, а в /etc/passwd есть следующие две строки, в этом порядке:

joe:xyzzy:2160:10:Joe User:/usr/joe:/bin/sh

jane:zzyxx:216:12:Jane User:/usr/jane:/bin/sh

2. Рассмотрите функцию makename(). Может ли она использовать sprintf() для составления имени? Почему может или почему нет?

3. Являются ли строки 319–320 в readdir() действительно необходимыми?

4. Возьмите программу stat, которую вы написали в качестве упражнения в «Упражнениях» к главе 6. Добавьте функцию nblock() из V7 ls и выведите результаты вместе с полем st_blocks из struct stat. Добавьте видимый маркер, когда они различны.

5. Как бы вы оценили V7 ls по ее использованию malloc()? (Подсказка: как часто вызывается free()? Где ее следовало бы вызвать?)

6. Как вы оценили бы ясность кода V7 ls? (Подсказка: сколько там комментариев?)

7. Очертите шаги, которые нужно было бы сделать, чтобы адаптировать V7 ls для современных систем.

Глава 8
Файловые системы и обходы каталогов

Данная глава завершает обсуждение файловых систем и каталогов Linux (и Unix). Сначала мы опишем, как к логическому пространству имен файловой системы добавляется (и удаляется) раздел диска, содержащий файловую систему, таким образом, что в общем пользователю не нужно ни знать, ни заботиться о месте физического размещения файла, вместе с API для работы с файловыми системами

Затем мы опишем, как перемещаться по иерархическому пространству имен файлов, как получать полный путь текущего рабочего каталога и как без труда обрабатывать произвольные иерархии (деревья) каталогов, используя функцию nftw(). Наконец, мы опишем специализированный, но важный системный вызов chroot().

Унифицированное иерархическое пространство имен файлов является большим достоинством дизайна Linux/Unix. Данный раздел рассматривает, как административные файлы, команды и операционная система объединяются для построения пространства имен из отдельных физических устройств, содержащих данные и служебные данные файлов.

В главе 5 «Каталоги и служебные данные файлов», были представлены индексы для служебных данных файлов и описано, как элементы каталогов связывают имена файлов с индексами В ней также были описаны разделы и файловые системы, и вы видели, что прямые ссылки ограничены работой в пределах одной файловой системы, поскольку каталоги содержат лишь номера индексов, а последние не уникальны среди всего набора использующихся файловых систем.

Помимо индексов и блоков данных, файловые системы содержат также одну или более копий суперблока. Это специальный дисковый блок, который описывает файловую систему; его сведения обновляются по мере изменений в самой файловой системе. Например, он содержит число свободных и используемых индексов, свободных и используемых блоков и другие сведения. Он включает также магическое число: специальное уникальное значение в специальном месте, которое идентифицирует тип файловой системы (Вскоре мы увидим, насколько это важно.)

Обеспечение доступа к разделу, содержащему файловую систему, называется монтированием (mounting) файловой системы. Удаление файловой системы из использования называется, что неудивительно, демонтированием (unmounting) файловой системы.

Эти две задачи выполняются программами mount и umount [так], названными по соответствующим системным вызовам. У системного вызова mount() каждой системы Unix свой, отличный интерфейс. Поскольку монтирование и демонтирование считаются проблемой реализации, POSIX намеренно не стандартизует эти системные вызовы

Вы монтируете файловую систему в каталог; такой каталог называется точкой монтирования файловой системы. По соглашению, каталог должен быть пустым, но ничто не принуждает к этому. Однако, если точка монтирования не пуста, все ее содержимое становится , пока в ней не смонтирована файловая система[76]76
  GNU/Linux и Solaris дают возможность монтировать один файл поверх другого; это продвинутое использование, которое мы не будем обсуждать – Примеч. автора.


[Закрыть].

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

Как упоминалось ранее, программы уровня пользователя помещают структуры индексов и другие вспомогательные данные на раздел диска, создавая тем самым файловую систему. Эти самые программы создают для файловой системы начальный корневой каталог. Таким образом, нам придется провести различие между «корневым каталогом, названным /», который является каталогом самого верхнего уровня в иерархическом пространстве имен файлов, и «корневым каталогом файловой системы», который является отдельным каталогом верхнего уровня каждой файловой системы. Каталог / является также «корневым каталогом» «корневой файловой системы».

По причинам, описанным на врезке, у корневого каталога файловой системы номер индекса всегда равен 2 (хотя это не стандартизовано формально). Поскольку может быть несколько файловых систем, у каждой из них один и тот же номер индекса корневого каталога 2. При разрешении пути ядро знает, где смонтирована каждая файловая система и заставляет имя точки монтирования ссылаться на корневой каталог смонтированной файловой системы. Более того, '..' в корне смонтированной файловой системы ссылается на родительский каталог точки монтирования.

На рис. 8.1 показаны две файловые системы: одна для корневого каталога, а другая для /usr, до того, как /usr смонтирована. На рис. 8.2 показана ситуация после монтирования /usr.

Рис. 8.1. Отдельные файловые системы до монтирования

Рис. 8.2. Отдельные файловые системы после монтирования

Каталог /, корень всей логической иерархии, особый еще в одном отношении: /. и /.. ссылаются на один и тот же каталог; это неверно для любого другого каталога в системе. (Таким образом, после команды типа 'cd /../../../..' вы все еще будете в /.) Это поведение реализуется простым способом: как /., так и /.. являются прямыми ссылками на корневой каталог файловой системы. (Вы можете видеть это как на рис. 8.1, так и 8.2.) Каждая файловая система работает таким способом, но ядро рассматривает / особым образом и не рассматривает как особый случай каталог '..' для файловой системы, смонтированной в /.

Номера индексов корневого каталога

Номер индекса для корневого каталога файловой системы всегда равен 2. Почему это так? Ответ имеет отношение как к технологии, так и к истории.

Как упоминалось в разделе 5.3 «Чтение каталогов», элемент каталога с номером индекса ноль означает неиспользуемый, или пустой слот. Поэтому индекс 0 не может использоваться для настоящего файла или каталога.

Хорошо, так что насчет индекса 1? Ну, особенно в 70-80 годах XX века, диски не были сделаны так же хорошо, как сейчас. Когда вы покупали диск, он приходил с (бумажным) списком испорченных блоков – известных мест на диске, которые не могли быть использованы. Каждой операционной системе приходилось отслеживать эти плохие блоки и избегать их использования.

Под Unix это осуществлялось созданием файла особого назначения, блоки данных которого были известны, как испорченные. Этот файл присоединялся к индексу 1, оставляя 2 в качестве первого индекса, доступного для использования обычными файлами или каталогами.

На современных дисках присутствует значительное количество встроенной электроники, и они сами управляют испорченными блоками. Поэтому технически было бы осуществимо использовать для файла индекс 1. Однако, поскольку такое большое количество программ Unix, которые предполагают, что индекс 2 является индексом для корневых каталогов файловых систем, Linux также следует этому соглашению. (Однако, Linux иногда использует индекс 1 для не собственных файловых систем, таких, как vfat или /proc.)

ЗАМЕЧАНИЕ. Обсуждение в данном разделе специфично для Linux. Однако, у многих современных систем Unix также есть сходные особенности. Мы рекомендуем вам изучить документацию своей системы.

Исторически V7 Unix поддерживал лишь один тип файловой системы; вспомогательные данные и организация каталогов каждого из разделов были структурированы одним и тем же способом. 4.1 BSD использовал файловую систему с такой же как у V7 структурой, но с размером блока 1024 байта вместо 512 байтов. 4.2 BSD ввело «файловую систему BSD», которая разительно изменила расположение индексов и данных на диске и дала возможность использовать гораздо большие размеры блоков. (В общем, использование больших протяженных блоков данных обеспечивает лучшую производительность, особенно для чтения файлов.)

Вплоть до 4.3 BSD и System V Release 2 в начале и середине 1980-х системы Unix продолжали поддерживать один тип файловой системы. Для переключения компьютера от одной файловой системы на другую[77]77
  Например, при обновлении VAX 11/780 с 4.1 BSD до 4.2 BSD – Примеч. автора.


[Закрыть] приходилось сначала резервировать каждую файловую систему на среду архивирования (9-дорожечную ленту), обновлять систему, а затем восстанавливать данные.

В середине 1980-х Sun Microsystems разработала архитектуру ядра, которая сделала возможным использование нескольких архитектур файловой системы в одно и то же время. Этот проект был реализован в их операционной системе SunOS, сначала для поддержки сетевой файловой системы Sun (Network File System – NFS). Однако, как следствие, стало возможным также поддерживать несколько архитектур на диске. System V Release 3 использовала сходную архитектуру для поддержки удаленной файловой системы (Remote File System – RFS), но она продолжала поддерживать лишь одну архитектуру на диске.[78]78
  System V Release 3 поддерживала два различных размера блоков: 512 байтов и 1024 байта, но в остальном организация диска была той же самой – Примеч. автора.


[Закрыть] (RFS никогда широко не использовалась и сейчас является лишь исторической сноской.)

Общий дизайн Sun стал популярным и широко реализовывался в коммерческих системах Unix, включая System V Release 4. Системы Linux и BSD используют разновидность этого дизайна для поддержки множества форматов файловых систем на диске. В частности, обычным для всех разновидностей Unix на платформе Intel x86 является возможность монтирования файловых систем MS-DOS/Windows FAT, включая поддержку длинных имен, а также форматированные в соответствии с ISO 9660 CD-ROM.

Linux имеет несколько собственных (т.е. размещаемых на диске) файловых систем. Наиболее популярными являются файловые системы ext2 и ext3. Однако, доступно значительно больше файловых систем. Сведения о большинстве из них вы можете найти в каталоге /usr/src/linux/Documentation/filesystems/ (если вы установили исходный код ядра). В табл. 8.1 перечислены имена различных файловых систем с кратким описанием каждой из них. Сокращение «RW» означает «чтение/запись», a «RO» означает «только чтение».

Таблица 8.1. Поддерживаемые ядром файловые системы Linux (ядро 2.4.x)

Не все из этих файловых систем поддерживаются командой mount; список поддерживаемых см. в mount(8).

Журналирование является методикой, впервые использованной в системах баз данных для увеличения производительности обновлений файлов таким образом, что восстановление файловой системы в случае аварии могло быть сделано быстро и правильно. В момент написания этого были доступны несколько различных журналируемых файловых систем, конкурирующих за продвижение в мире GNU/Linux. Одной из них является ext3; у нее преимущество обратной совместимости с существующими файловыми системами ext2, очень просто конвертировать файловые системы туда-сюда между этими двумя видами (См. tune2fs(8).) ReiserFS и XFS также имеют своих твердых сторонников.

Файловые системы fat, msdos, umsdos и vfat все разделяют общий исходный код. В общем, можно использовать vfat для монтирования разделов Windows FAT-32 (или другой FAT-xx), a umsdos, если нужно использовать раздел FAT в качестве корневой файловой системы для GNU/Linux.

Файловые системы Coherent, MINIX, первоначальной System V и Xenix все имеют сходные структуры на диске. Тип файловой системы sysv поддерживает все из них; четыре имени coherent, minix, sysv и xenix являются псевдонимами один для другого. Имена coherent и xenix в конечном счете будут удалены.

Быстрая файловая система BSD в течение нескольких лет успешно развилась. Файловая система ufs поддерживает операции чтения/записи для версий, начиная с 4.4 BSD, которая является основой для трех широко распространенных операционных систем BSD: FreeBSD, NetBSD и OpenBSD. Она поддерживает также операции чтения/записи для файловой системы Sun Solaris как для SPARC, так и для систем Intel x86. Первоначальный формат BSD и формат операционной системы NeXTStep поддерживаются в режиме только для чтения.

Обозначения «RO» для befs и ntfs означают, что файловые системы этих типов можно смонтировать и читать, но в них невозможно записать файлы или удалить из них файлы. (Со временем это может измениться; проверьте документацию своей системы.) Файловые системы cramfs, iso9660, romfs и udf отмечены «RO», поскольку лежащее в их основе средство по своей сути является устройством только для чтения.

Две файловые системы, которых больше не существует, это ext, которая была оригинальной расширенной файловой системой, и xiafs, которая расширяла оригинальную файловую систему MINIX для использования длинных имен и больших размеров файлов, xiafs и ext2 появились примерно в одно время, но ext2 в конечном счете стала доминирующей файловой системой.[80]80
  Источник: http://www.ife.ee.ethz.ch/music/software/sag/subsection2_5_4_3.html – Примеч. автора.


[Закрыть]