3.6.5. Нові версії системи fat
Структури даних файлової системи є однією з найбільш консервативних, погано піддаються змінам характеристик ОС. Проблема полягає в тому, що при змінах структур даних важко зберегти сумісність з більш ранніми версіями. Було б катастрофою, якби всі безліч накопичених у світі файлів в системі FAT раптом перестало читатися в новій версії системи. Тим не менш, деякі цікаві зміни все ж вдалося ввести при випуску версій Windows 95 і 98.
У Windows 95 було подолано прикре обмеження довжини імені файлу - знамените правило «8 + 3». Здавалося б, при розмірі записі каталогу в 32 байта важко сподіватися на довгі імена файлів. Тим не менш, було знайдено забавне рішення цієї проблеми.
Розробники з Microsoft звернули увагу, що ті записи каталогу, в яких зустрічається безглузда комбінація бітових атрибутів «прихований + системний + тільки читання + мітка тому», просто-напросто ігноруються як системними програмами MS-DOS, так і поширеними утилітами інших розробників. Це дало можливість використовувати записи з такою комбінацією для зберігання довгого імені файлу. Як і раніше для кожного файлу в каталозі є основна запис у звичайному, старому форматі, що містить атрибути файлу, номер першого кластера і обов'язкове «короткий» ім'я. Однак якщо користувач при створенні файлу вказує ім'я, яке не вкладається в стандарт «8 + 3» або містить малі літери, то перед основною записом буде вставлено потрібну кількість додаткових записів з розбитим на шматочки «довгим ім'ям» в кодуванні UNICODE (по 2 байти на символ , що дозволяє використовувати будь-який відомий алфавіт). Довжина імені, згідно з документацією, може досягати 255 символів (насправді, трохи менше).
Починаючи з Windows 98, з'явилася можливість використовувати новий різновид файлової системи - FAT-32. Її відмінність від FAT-12 і FAT-16 полягає не тільки в більшої розрядності номера кластера (хоча і це дуже важливо для великих дисків), але і в тому, що Microsoft нарешті зважилася використовувати 10-байтовий резерв, який невідомо для яких цілей зберігався незайнятим в кожному записі каталогу. Завдяки цьому з'явилася можливість додати до дати / часу
останньої модифікації файлу ще два тимчасових штампа: дату / час створення (насправді, це дата / час останньої зміни каталожної записи) і дату останнього доступу до файлу.
3.7. Файлові системи і управління даними в unix
3.7.1. Архітектура файлової системи unix
Тут розглядається класична файлова система UNIX, звана іноді системою s5fs і підтримувана всіма версіями UNIX. Сучасні удосконалення файлової системи будуть розглянуті в п. 3.7.4.
3.7.1.1. Жорсткі і символічні зв'язку
Структуру каталогів файлової системи UNIX називають іноді мережевий, щоб підкреслити її відмінність від строго ієрархічної (деревної) структури каталогів таких систем, як, наприклад, FAT. Відмінність ця полягає в поняттях жорстких і символічних зв'язків файлу.
Жорстка зв'язок означає зв'язок між ім'ям файлу і самим файлом. Особливість UNIX в тому, що будь-який файл може мати декілька (точніше, необмежена кількість) жорстких зв'язків, тобто необмежену кількість імен. Це можуть бути різні імена в одному каталозі або навіть ім'я, збережене в різних каталогах одного дискового тому.
Чи є якась користь від кількох імен одного файлу? Безумовно, є. Припустимо, користувач часто використовує якусь системну програму або файл даних, що лежить десь глибоко в одній з гілок дерева каталогів. Замість того, щоб кожного разу вказувати довгий шлях до потрібного файлу, користувач може просто створити нову жорстку зв'язок, тобто дати файлу зручне ім'я і помістити це ім'я у свій особистий каталог. UNIX надає для цього команду link, яка створює нове ім'я для зазначеного файлу.
Що станеться, якщо один з користувачів видалить ім'я файлу з каталогу? Відбудеться тільки обрив однієї з жорстких зв'язків. Поки у даного файлу залишаються інші імена, файл продовжує існувати. Тільки після того, як видалені всі імена файла, система розуміє, що файл перестав бути доступний будь-кому, і видаляє сам файл.
Всі жорсткі зв'язку (імена) одного файлу абсолютно рівноправні, серед них можна виділити якесь «основне» ім'я.
Дещо іншим чином працює символічна зв'язок. Такий зв'язок являє собою файл, який містить тільки повне ім'я іншого файлу. Важливо при цьому те, що файл позначений в системі саме як символічний зв'язок, а не просто текстовий файл, випадково зберігає ім'я файлу. Коли файл символічної зв'язку використовується як аргумент системної команди або функції, UNIX автоматично підставляє замість нього той файл, на який вказує зв'язок.
Можна коротко сказати, що жорстка зв'язок вказує на сам файл, а символічна - на ім'я файлу. Обидва типи зв'язків проілюстровані на рис. 3-4.
Рис. 1‑13
У прикладі на малюнку показаний файл даних, для якого є три жорсткі зв'язки, тобто три імені в каталогах системи, позначені як «Ім'я 1», «Ім'я 2» і «Ім'я 3». Крім того, в системі є файл типу «символічний зв'язок», який містить одне з імен файлу даних. Файл символічної зв'язку, як і будь-який інший файл, доступний по імені і в даному випадку має два імені (дві жорстких зв'язку): «Ім'я
4» і «Ім'я 5». Таким чином, використання будь-якого з п'яти імен в якості, наприклад, імені файлу, що відкривається приведе до відкриття одного і того ж файлу.
Припустимо, адміністратор системи вирішив замінити деякий файл його більш свіжою версією, залишивши те ж саме ім'я файлу. Якщо деякі користувачі зберігали жорсткі зв'язки на колишню версію, то вони так і будуть нею користуватися, поки явно не видалять її ім'я і не створять зв'язку на нову версію. Якщо ж користувач зберігав символічний зв'язок, то вона тепер буде вказувати на нову версію.
У Windows використовується певний аналог поняття символічної зв'язку - ярлик файлу (shortcut). Відмінність у тому, що з точки зору файлової системи Windows ярлик не є якимось особливим типом файлу, це звичайний текстовий файл з розширенням LNK. Ярлик розпізнається не файловою системою, а такими програмами, як Провідник (Explorer).