1.1.3. Захист файлів

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

Тому в більшості сучасних систем управління файлами застосовується підхід до захисту файлів, уперше реалізований в ОС UNIX. У цій системі кожному зареєстрованому користувачеві відповідає пара цілочисельних ідентифікаторів: ідентифікатор групи, до якої відноситься цей користувач, і його власний ідентифікатор в групі. Відповідно, при кожному файлі зберігається повний ідентифікатор користувача, який створив цей файл, і відмічається, які дії з файлом може проводити він сам, які дії з файлом доступні для інших користувачів тієї ж групи, і що можуть робити з файлом користувачі інших груп. Ця інформація дуже компактна, при перевірці потрібна невелика кількість дій, і цей спосіб контролю доступу задовільний в більшості випадків.

1.1.4. Режим багатокористувацького доступу

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

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

Помітимо, що в ранніх версіях файлової системи ОС UNIX взагалі не були реалізовані які б те не було засобів синхронізації паралельного доступу до файлів. Операція відкриття файла виконувалася завжди для будь-якого існуючого файла, якщо даний користувач мав відповідні права доступу. При спільній роботі синхронізацію потрібно було проводити поза файловою системою (і особливих коштів для цього ОС UNIX не надавала). У сучасних реалізаціях файлових систем ОС UNIX за бажанням користувача підтримується синхронізація при відкритті файлів. Крім того, існує можливість синхронізації декількох процесів, що паралельно модифікують один і той же файл. Для цього введений спеціальний механізм синхронізаційних захоплень діапазонів адрес відкритого файла.

1.2. Сфери застосування файлів

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

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

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

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

1.3. Потреби інформаційних систем

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