| Стандарт побудови файлової системи | Квітень, 12, 2000 | |
| Вперед | Що де є | Назад |
Це версія 2.1 стандарту побудови файлової системи (СПФС 2.1)(Filesystem Hierarchy Standard (FHS 2.1)).
Вітаються коментарі до цього стандарту від всіх зацікавлених сторін. Пропозиції про зміни мають бути у вигляді пропонуємих змін тексту разом з необхідними коментарями, що їх обгрунтовують.
Настанови в цьому стандарті не є остаточними. Використовуйте інформацію з цього документу на власний розсуд та ризик.
Стандарт розбито на такі розділи:
/usr./var.В межах кожного розділу підкаталоги подано за ASCII порядком (спочатку великі літери, потім за абеткою) для полегшення посилання.
Шрифт сталої ширини використано для відображення назв файлів та каталогів.
Частини назв файлів, що змінні, подано в кутових дужках "<" та ">", як оце <отак>.Адреси електронної пошти також забрано в "<" та ">", але подано звичайним шрифтом.
Необов'язкові частини назв файлів забрано в прямі дужки "[" та "]" і це може бути поєднано з домовленністю вище. Наприклад, якщо ім'я файлу може бути використане з розширенням або без, це буде мати такий вигляд <filename>[.<extension>].
Змінні частини назв каталогів та файлів позначено "*".
Зусилля з розробки стандарту побудови файлової системи було започатковано в серпні 1993 р. з метою вдосконалення правил розташування файлів та каталогів в Linux. FSSTND, стандарт побудови файлової системи для операційної системи Linux, було ухвалено 14 лютого 1994 р. Послідовні перегляди робилися 9 жовтня 1994 р. та 28 березня 1995 р.
На початку 1995 р., за участі членів товариства розробників BSD, була узгоджена ціль розробки більш загальної версії FSSTND, що стосувалася б не тільки Linux, а всіх Unix подібних систем. Як наслідок, зусилля було сконцентровано на проблемах, що є загальними для усіх Unix подібних систем. Щоб відобразити цю зміну орієнтації зусиль, назва стандарту було змінено на Стандарт побудови файлової системи або СПФС для стислості.
Добровольці, які зробили значний внесок до цього стандарту, перераховані на завершення цього документу. Цей стандарт є узгодженою думкою цих та інших вкладників.
Цей документ визначає стандарт побудови файлової системи для СПФС файлових систем шляхом визначення місця розміщення файлів та каталогів і змісту деяких системних файлів.
Цей стандарт розроблено для використання системними інтеграторами, розробниками пакетів та керуючими системами при побудові та обслуговуванні СПФС сумісних файлових систем. Перш за все, це - довідник, а не підручник, як керувати відповідною файловою системою.
СПФС "виріс" з раніше складеного FSSTND стандарту побудови файлової системи в операційній системі Linux. Його побудовано на FSSTND щоб вирішити проблему взаємодії не тільки в товаристві Linux, а й у більш широких межах, зокрема, включити системи, що базуються на 4.4 BSD. Він враховує здобутки світу BSD та все інше, що стосується підтримки різних архітектур та запити гетерогенних мереж.
Хоча цей стандарт є більш прийнятним, ніж попередні спроби в стандартизації побудови файлових систем, періодичні оновлення можуть бути необхідними з метою врахування потреб розвитку новітніх технологій. Можливо також, що буде знайдено краще вирішення для проблем, що тут розглянуто, і наші рішення вже не будуть кращими. Додаткові проекти можуть бути виконані поза періодичними оновленнями цього документу. Проте, зворотня сумісність всіх версій цього документу є окремою метою проекту.
Коментарі до цього стандарту заохочуються. Всі коментарі або пропозиції про зміни повинні надсилатися редактору СПФС (Даніелю Куінлану (Daniel Quinlan) <quinlan@pathname.com>) або, коли вам так буде зручніше, до СПФС розсилки. Типографські або граматичні коментарі мають надсилатися прямо редактору СПФС.
До звертання в групу обговорення, треба зв'язатися з редактором СПФС для уникнення початку нового обговорення вже узгоджених тем. Листи, що не підписані, не будуть вітатися в групі.
Питання, як трактувати окремі позиції з цього документу, іноді можуть виникати. Коли вам потрібні такі роз'яснення, будьласка, звертайтеся до редактора СПФС. Оскільки цей стандарт являє собою узгоджену думку багатьох учасників, дуже важливо бути впевненим, що кожне роз'яснення також є їх спільною думкою. Виходячи з цього, роз'яснення може дещо затриматися, коли питання виникає вперше.
Це деякі положення якими керувалися при розробці цього стандарту:
Цільова аудиторія цього стандарту охоплює наступні групи людей, але ними не обмежується:
Тут визначено значення термінів "узгоджується" та "сумісний" з цим стандартом, а також "частково узгоджується" та "частково сумісний".
"Виріб" тут визначає комплект, встановлену систему, програму, пакунок (або певна частина програмного забезпечення або данних) або їх певний компонент.
Виріб повністю узгоджується з цим стандартом якщо виконані всі вимоги стандарту. Кожен файл чи каталог, що є частиною виробу, повинні бути фактично розміщені як зазначено в цьому документі. Коли зміст файлу описано тут, фактичний зміст має бути як описано. Виріб має також намагатися шукати будь які файли та каталоги, навіть зовнішні по відношенню до нього, спочатку або тільки в місцях визначених цим стандартом.
Для стислості, "узгоджується" може бути рівноцінно використано замість "повністю узгоджується".
Виріб є повністю сумісним з цим стандартом, коли всі файли або каталоги, що до нього входять, можуть бути знайдені через пошук в місцях зазначених тут і з змістом як тут зазначено, навіть коли це не основне або фізичне місце знаходження файлів чи каталогів, що їх шукають.Продукт повинен, коли намагається шукати будь-які файли або каталоги, що не є його частиною, робити це в місцях, що визначені цим стандартом, але може намагатися шукати і в інших (не зазначених в цьому стандарті) місцях.
Для стислості, "сумісний" може бути рівноцінно використано замість "повністю сумісний".
Виріб є частково узгодженим або частково сумісним відповідно, коли він узгоджується або сумісний з суттєвою частиною цього документу. Частково сумісний або частково узгоджений може застосовуватися тільки до комплектів, а не до окремих програм. Поняття "суттєва частина" є дуже суб'єктивним і, в означених випадках, зацікавлена сторона має контактувати з редактором СПФС. Очікується, що деякі варіації будуть можливі в означених випадках.
Щоб бути частково узгодженим з СПФС або частково сумісним з СПФС, виріб повинен подавати перелік всіх випадків в яких він та СПФС документ різняться додатково до пояснень сенсу цих розбіжностей. Цей перелік має бути разом з виробом в запиті і також повідомлений та висланий в СПФС розсилку або редактору СПФС.
Терміни "повинно", "є", "містить" і т.ін. треба читати як вимоги на сумісність або узгодженість.
Зазначимо, що виробу не треба мати всі файли та каталоги визначені в цьому стандарті щоб бути узгодженим або сумісним. Тільки файли та каталоги, що дійсно є в виробі повинні бути розташовані вірно. Наприклад, коли певна файлова система комплектом не підтримується, відповідні інструменти не треба включати, навіть коли вони явно перелічені в цьому стандарті.
Більш того, певні частини цього документу є необов'язковими. Це буде зазначено явно або помічено використанням одного або більше "може", "рекомендовано" або "пропонується". Пункти, що зазначені як бажані, не впливають на сумісність чи узгодженість виробу; це - пропозиції, на зоохочення загальної практики, та можуть бути розміщені будь де за вибором виробника.
Перекладено А. М. Добровольським © 2000 р.
| Вперед | Що де є | Назад |