Світ на трьох кашалотів мається 2

Класифікація файлів

Старий користувач DOS / Windows, що не погрузла остаточно в метафорі файлів-документів, що виникла в MacOS (де, треба віддати їй належне, метафора ця цілком виправдана) і впровадженої в Windows, пам'ятає про існування типів файлів, що відрізняються своїми розширеннями, - виконуваних (* .exe. * .com), пакетних (* .bat), текстових (* .txt), зображень в різних форматах (* .tiff там, або * .gif) і так далі. І тому буде дуже здивований, коли дізнається, що в UNIX'ах всі вони не типізовані ніяк. І дійсно - як ОС може відрізнити їх один від одного, якщо імені файлу (і, отже, розширення) в атрибутах його немає і в помині? У цьому сенсі говорять, що у FreeBSD немає поняття типізації файлу.

Насправді кошти для розрізнення файлів з контентом різного роду існують і у FreeBSD, але це зазвичай прерогатива додатків, а не самої ОС, і про них зараз мова не буде.

Проте, під поняття файлу в POSIX-системах підпадають настільки різнорідні об'єкти, що вони неминуче вимагають класифікації. Інша справа, що класифікація ця заснована на абсолютно інших принципах. А саме, виділяються наступні типи файлів (і тип в даному випадку - це атрибут, описаний у відповідному полі inode кожного файлу):

каталоги;
символічні посилання;
спеціальні файли пристроїв;
іменовані канали і сокети;
звичайні, або регулярні, файли.

Отже, каталоги (по-англійськи directory) - тип файлів, в деякому сенсі протиставляє всім іншим типам оних. Це - спеціальні файли, які об'єднують інші файли (і підкаталоги, звані також вкладеними каталогами) в відокремлені одна від одної групи (по крайней мере, так вони бачаться користувачеві в спеціальних програмах управління файлами - файлових менеджерах).

У російськомовній літературі по DOS / Windows каталоги зазвичай іменуються директоріями, а останнім часом в ужиток увійшов термін "папка" (по-англійськи folder). Не дивлячись на те, що він встиг вже проникнути і в наші сфери (по крайней мере, в KDE, Xfce і так далі), для Unix-систем термін "каталог" краще, і я зараз спробую пояснити, чому.

Прийнята в Windows (і що йде історично від MacOS) метафора каталогу як папки з документами здатна створити враження (і часом його створює), що каталог - це якесь фізичне вмістилище включених в нього файлів. Але це не так. Каталоги - суть не більше ніж списки імен входять до них файлів і тих самих числових ідентифікаторів, про які йшлося в попередньому розділі (і за якими власне дані і знаходяться системою). І тому метафора бібліотечного каталогу (або книжкового змісту) як не можна краще відображає фізичний зміст відповідного поняття.

Роль каталогів важко переоцінити. Тому що ім'я файлу в файлової системі FreeBSD існує тільки в складі каталогу, і ніяк інакше - як ми пам'ятаємо, серед атрибутів власне файлу його немає. Власне ж вміст файлу ставиться у відповідність імені через ідентифікатор його inode. подібно до того, як це здійснюється в базах даних. Механізм співвіднесення імені файлу, його метаданих і даних носить назву жорсткої посилання (hardlink), щоб відрізнити його від посилань символічних - файлів особливого типу, про які йтиметься в наступному розділі. Кількість жорстких посилань і є значення поля лічильника в inode файлу. Очевидно, що можливий його мінімум для більшості типів файлів - одиниця.

Зі сказаного випливає кілька важливих властивостей імен файлів. Ідентифікатора пристрою, який несе даний файл, в каталозі немає. І тому ім'я файлу (тобто елемент включає його каталогу) може існувати тільки в тій же фізичної файлової системи (розділі), що і inode. з яким він пов'язаний жорсткої посиланням (і, зрозуміло, в тій же, що і власне область даних файлу).

Підкреслю, що два імені файлу, пов'язаних жорсткої посиланням з одним і тим же inode. не є копією один одного, оскільки при копіюванні файлу створюються нові області метаданих і даних, які в подальшому будуть існувати абсолютно незалежно один від одного - тобто зміна вмісту копії або її атрибутів ніяк не торкнеться вихідний файл.

Поки будь-який файл відкритий, тобто існує посилається на нього процес, він продовжує існувати, навіть якщо ім'я його виключено з усіх каталогів, і може бути записаний, скопійований, перейменований, і т.д. Тобто відкритий якихось процесом дескриптор даного файлу - гарантія його існування, принаймні, до завершення процесу. Саме тому я раніше сказав, що файл не обов'язково має ім'я: в разі видалення відкритого файлу з каталогу він деякий час існує як би безіменним, для підтримки його буття досить відкритого дескриптора, асоційованого з inode.

Однак повернемося до каталогів. Як ми тільки що побачили, будь-який файл доступний для системи в тій разі, якщо він включений, пардон за подвійну тавтологію, в файлову систему. Тобто ім'я його приписано до певного каталогу. Але ж каталог - це теж файл, і він теж повинен бути приписаний до якогось каталогу більш високого рівня, який носить назву батьківського. І цей батьківський каталог (символічно він позначається як.) - один з елементів будь-якого, навіть не містить як би файлів, каталогу. А другий його неодмінний елемент - це він сам, тобто поточний каталог (що символізується так -.). Тобто для каталогу мінімум можливих зв'язків (значення поля лічильника в inode), на відміну від всіх інших типів файлів, дорівнює 2.

Отже, кожен файл входить в будь-якої каталог, який, в свою чергу, включений в каталог більш високого рівня і так далі. Аж до самого високого каталогу, не цілком логічно іменованого кореневих, за яким зарезервований символ /. Вся ця конструкція називається деревом файлової системи (хоча на ілюстраціях в більшості книжок це дерево росте зазвичай зверху вниз), файлової системою просто (як скоро стане ясним, це - один з найбільш багатозначних термінів у всій околокомпьютерной літературі) або, нарешті, файлової ієрархією ( тобто ієрархією файлів і каталогів). На останньому терміні ми і зупинимося, а до роз'яснення його суті звернемося в одній з наступних глав.