Досистемний етап завантаження.

1.Завантажувач з ПЗУ визначає, з яких пристроїв можна грузиться і, можливо, пропонує користувачеві вибрати одне з них. Він завантажує з вибраного пристрою первинний завантажувач і передає йому управління.

2.Первинний завантажувач визначає (а найчастіше - знає), де знаходиться вторинний завантажувач - велика і досить розумна програма. Йому це зробити простіше, ніж програмі з ПЗУ: по-перше, тому що для кожного пристрою первинний завантажувач свій, а по-друге, тому що його можна легко змінювати при зміні налаштувань завантажуваної системи. У схемі, запропонованій LILO і GRUB, первинний завантажувач не вступає в розмови з користувачем, а негайно завантажує вторинний і передає йому управління.

3.Вторинний завантажувач досить розумний, щоб знати, де знаходиться ядро ​​системи (можливо, не одне), пропонувати користувачу кілька варіантів завантаження на вибір, і навіть, в разі GRUB, дозволяє задавати власні варіанти завантаження. Його завдання - завантажити в пам'ять ядро ​​і все необхідне для старту системи (іноді - модулі, іноді - стартовий віртуальний диск), налаштувати все це і передати управління ядру.

42. Системний етап завантаження. Реалізація системного етапу завантаження Linux.

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

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

Потім ядро ​​запускає кілька процесів ядра. Процес ядра - це частина ядра Linux, зареєстрована в таблиці процесів. Такому процесу можна послати сигнал і взагалі користуватися засобами між процесами взаємодії, на нього поширюється політика планувальника завдань, проте ніякої задачі в режимі користувача він не відповідає, це просто ще одна іпостась ядра. Команда ps-ef показує процеси ядра в квадратних дужках, крім того, в Linux прийнято (але не обов'язково), щоб імена таких процесів починалися на «k»: [kswapd], [keventd] і т. п.

Далі ядро ​​підключає (монтує) кореневу файлову систему відповідно до переданих параметрів (в наших прикладах - root = / dev/hda5). Підключення це відбувається в режимі «тільки для читання» (read-only): якщо цілісність файлової системи порушена, цей режим дозволить, не посилюючи положення, прочитати і запустити утиліту fsck (file system check). Пізніше, в процесі завантаження, коренева файлова система підключиться на запис.

Нарешті, ядро ​​запускає з файлу / sbin / init перший справжній процес. Ідентифікатор процесу (PID) у нього дорівнює одиниці, він - перший у таблиці процесів, навіть незважаючи на те, що до нього там були зареєстровані процеси ядра. Процес init - дуже, дуже старе винахід, він мало не старше самої історії (історії UNIX, звичайно), і з давніх пір його ідентифікатор дорівнює 1.
З запуску init починається завантаження самої системи

43. Процес init. Файли /etc/inittab, /etc/rc.d/rc.sysinit.

Init є батьком всіх процесів. Його головне завдання - створювати процеси за сценарієм з файлу / etc / inittab. У цьому файлі зазвичай містяться записи, що вказують init породити getty для кожної лінії, по якій користувачі можуть входити в систему. Він також контролює автономні процеси, необхідні будь-якій системі. Рівень виконання - програмна конфігурація системи, яка дозволяє існувати тільки заданій групі процесів. Процеси, що породжуються init на кожному з таких рівнів виконання, визначаються у файлі / etc / inittab.
У процесі завантаження, після ініціалізації ядра, ядро ​​запускає / sbin / init як перший процес користувацького режиму. init відповідає за подальшу завантаження системи. Для цього він запускає так звані стартові скрипти, які виконують перевірку та монтування файлових систем, запуск необхідних демонів, налаштування ядра (у тому числі завантаження модулів ядра згідно встановленому обладнанню, настройку IP-адрес, таблиць маршрутизації та ін), запуск графічної оболонки і інші дії.

В операційних системах Unix / Linux за допомогою init можна змінити рівень ініціалізації. Рівень ініціалізації - ступінь завантаження операційної системи. Ось як відбувається ініціалізація системи: процес init запускається і аналізує файл / etc / inittab. Слід зазначити, що наведена тут система ініціалізації працює на системах Linux і Unix System V і вона дещо відрізняється від стилю ініціалізації системи в BSD-подібних системах.

За замовчуванням, в системі використано 7 рівнів ініціалізації:

0 - зупинка системи

1 - завантаження в режимі одного

2 - завантаження в многопользовательском режимі без підтримки мережі

3 - завантаження в многопользовательском режимі з підтримкою мережі

4 - не використовується

5 - завантаження в многопользовательском режимі з підтримкою мережі і графічного входу в систему

6 - перезавантаження

Набравши init n в терміналі (з правами суперкористувача), де n - номер рівня ініціалізації, можна переключитися в кожній з перерахованих вище рівнів.

si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1

l2:2:wait:/etc/rc.d/rc 2

l3:3:wait:/etc/rc.d/rc 3

l4:4:wait:/etc/rc.d/rc 4

l5:5:wait:/etc/rc.d/rc 5

l6:6:wait:/etc/rc.d/rc 6

1:2345:respawn:/sbin/mingetty tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6

x:5:respawn:/etc/X11/prefdm -nodaemon

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

1 - порядковий номер консолі

2345 - номери рівнів ініціалізації, для яких консоль ініціалізується

respawn - цей параметр означає, що init повинен перезапустити обслуговуючий консоль процес після виходу з сеансу або в разі краху.

/ sbin / mingetty tty6 - програма (із зазначенням параметрів), яка обслуговуватиме консоль.

Таким чином, ви легко можете створити свій рівень ініціалізації (під номером 4 або 7, 8 ...), просто виправивши файл / etc / inittab і створивши необхідні посилання в каталозі / etc / rc.d / rc *. D

44. Сценарії ініціалізації ОС. Приклади системних демонів.

В процесі ініціалізації можна виділити кілька етапів:

1) Розпізнавання і конфігурування пристроєм, ініціалізація драйверів і авто конфігурація ядра

2) Визначення і монтування кореневої файлової системи

3) Запуск основних системних демонів

4) Виконання ініціалізацій них сценаріїв

5) Запуск менеджерів дисплею і терміналів

Демон - це завдання, що виконується у фоновому режимі, і при запуску машини стартує ціла маленька армія таких. Бувають демони управління автоматизованими завданнями, демони для управління живленням і параметрами CPU, демони для друку і демони для ведення системних журналів. Деякі видають своє походження, додаючи до імен букву «d», інші воліють назви-ребуси навроде «binfmpt-support» або «brltty».

Демони, безсумнівно, невід'ємна частиною робочого оточення. Але є з ними і проблема. Без божественного осяяння звичайному дистрибутива Linux в точності не вгадати, які демони вам знадобляться, а які ні - в результаті всі вони норовлять перестрахуватися, аж до курйозів. Наприклад, ваш настільний комп'ютер може отримати демона управління живленням ноутбука або демона Bluetooth; працевлаштування обом не світить, але вони будуть завантажуватися і поїдати цінну пам'ять. Час завантаження і витрата пам'яті можна зменшити, трохи попрацювавши над відсіченням ваших демонів і їх підгонкою під свої вимоги. Весь фокус у тому, що саме потрібно видаляти.

Говорячи про демонів, більшість має на увазі сервіси. Часто вони стартують при завантаженні і скромно виконуються у фоновому режимі - але це не обов'язково легковагі засоби управління системою. Немає причин не вважати демонами і повні пакети додатків. Які сервіси виконувати, а які - ні, цілком залежить від вашого дистрибутива і цілей його застосування. Якщо ви використовуєте дистрибутив, орієнтований на серверне застосування, то досить імовірно, що в числі демонів буде web-сервер Apache разом зі своєю школою додатків-помічників. Це безпардонна побір ваших ресурсів, якщо web-сервер вам ні до чого, адже ще не так давно дистрибутиви типу Mandriva встановлювали і запускали web-сервер за замовчуванням. В наші кризові часи, швидше за все, такого не відбувається, але дуже ймовірно, що у вас все ще залишається небудь непотрібне, «крутиться» у фоновому режимі.
Приклади демонів: AppArmor, Apport, Avahi-deamon, Bluetooth, CUPS, GPM, KLogd, NTP, Powersaver, Powernowd, Laptop-mode.

45. Командний інтерпретатор. Базовий синтаксис команд. Шаблони вибору імен файлів.

46. Багатозадачність. Види реалізації багатозадачності.

47. Операційне середовище користувача та прикладних програм. Основні елементи операційного середовища. Організація сеансу роботи користувача через інтерфейс командного рядка.

48. Інструментальні засоби програмування. Основні відомості про мови програмування.

49. Загальні відомості про особливості розробки командних сценаріїв та програм на мові, що передбачає компіляцію.

Першою фазою є стадія компіляції, коли файли з вихідними текстами програми, включаючи файли заголовків, обробляються компілятором gсс (1). Параметри компіляції задаються або з допомогою файлу makefile, або явним зазначенням необхідних опцій компілятора в командному рядку. У підсумку компілятор створює набір проміжних об'єктних файлів. Традиційно імена створених об'єктних файлів мають суфікс «.о».

На наступній стадії ці файли за допомогою редактора зв'язків id зв'язується один з одним і з різними бібліотеками, включаючи стандартну бібліотеку за замовчуванням і бібліотеки, зазначені користувачем в якості параметрів. При цьому редактор зв'язків може виконуватися в двох режимах: статичному та динамічному, що задається відповідними опціями. У статичному, найбільш традиційному режимі зв'язуються всі об'єктні модулі і статичні бібліотеки (їх імена мають суфікс «.а»), проводиться дозвіл всіх зовнішніх посилань модулів і створюється єдиний виконуваний файл, що містить весь необхідний для виконання код. У другому випадку, редактор зв'язків по можливості підключає

спільні бібліотеки (імена цих бібліотек мають суфікс «.so»).В результаті створюється виконуваний файл, до якого в процесі запуску на виконання будуть підключені всі поділювані об'єкти. В обох випадках за умовчанням створюється виконуваний файл з ім'ям a.out

Для простих завдань усі фази автоматично виконуються викликом команди:

$ make prog або еквівалентній їй $ cc –o prog prog.c

які створюють виконуваний файл з ім'ям prog. У цьому випадку замовчуване ім'я виконуваного файлу(a.out) змінено на prog за допомогою опції –о.

Втім, вказані стадії можна виконувати і роздільно, з використанням команд сс і id. Зауважимо, що насправді команда cc являється програмною оболонкою і компілятора і редактора зв'язків, яку і рекомендується використовувати при створенні програм.

Проілюструємо процес створення більш складної програми за допомогою конкретних викликів команд.

$ cc –c file1. c file2.c Створимо проміжні об'єктні файли file1.o і file2.o

$ cc –o prog file1.o file2.o -lnsl Створимо виконуваний файл з ім'ям

prog, використовуючи проміжні об'єктні файли і бібліотеку або libnsl.a або libnsl.so

В оболонку вбудована мова програмування (командний мова), Що дозволяє писати складні командні сценарії. Саме командна мова відділяє оболонки один від одного, и саме з нього виходять користувачі, вибираючи оболонки

Linux є Unix-подібної ОС. Спочатку ОС Linux Була розроблено Лінусом Торвальдсом (Linus Torvalds) в університеті Хельсінкі (Фінляндія) на Основі ОС Minix - маленька UNIX-система, створ Andry Tanenbaum. Ранній Розвиток Linux насамперед Було пов'язано з проблемою перемикань Завдання в захіщеному режимі для 80386. І Лінус "ставши серйозно обдумувати маніакальну ідею, Як Зробити Minix краще собі самого".

Командна оболонка в системах UNIX-Вже існувала, Це Була оболонка "Bourne shell" (shell Баурна або просто shell). Трохи пізніше в UNIX-системах розробили оболонку C shell, Яка використовує Інший синтаксис,трохи нагадує синтаксис мови програмування Сі.

50. Компіляція та компоновка. Основні прийоми розробки початкових текстів, компіляції і компоновки програм. Статична компоновка. Динамічне зв’язування.

Компіляція — це процес перетворення початкової програми у виконувану. Процес компіляції складається з двох етапів. На першому етапі виконується перевірка тексту програми на відсутність помилок, на другому — генерується виконувана програма (ехе-файл).

Компоновка - приймає на вхід один або кілька об'єктних модулів і збирає у виконуваний модуль.

Для зв'язування модулів компонувальник використовує таблиці імен ідентифікаторів, створені компілятором в кожному з об'єктних модулів. Такі імена можуть бути двох типів:

· Певні або експортовані назви функцій та змінних, визначені в даному модулі і надані для використання іншим модулям.

· Невизначені або імпортовані імена - функції та змінні, на які посилається модуль, але не визначає їх в середині себе

Для динамічного зв’язування використовуються так звані віртуальні методи. Віртуальний метод визначають у деякій ієрархії класів так, щоб в усіх описах цього методу кількість та типи параметрів співпадали.

Наявність віртуальних методів у класі (а отже, динамічного зв’язування) обумовлює необхідність ініціалізації всіх об’єктів цього класу. Така ініціалізація здійснюється спеціальними методами, які називають конструкторами. Конструктор повинен викликатись раніше, ніж будь які інші дії над об’єктом класу. Клас може мати декілька конструкторів, наприклад, клас File може мати конструктор Create для створення нового файлу та конструктор Open для відкриття існуючого.

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

Статичне компонування дозволяє покращити переносимість програм, а динамічне дозволяє зменшити розмір програм.

51. Створення та підключення бібліотек. Види бібліотек. Управління вибором способу підключення бібліотек, наявних у двох варіантах.

З точки зору комп'ютерних наук бібліотеки діляться на статичні та динамічні.

Статичні бібліотеки можуть бути у вигляді початкового тексту, що підключається програмістом до своєї програми на етапі написання (наприклад, для мови Fortran існує величезна кількість бібліотек для вирішення різних завдань саме в початкових текстах), або у вигляді об'єктних файлів, що приєднуються (лінкуються) до виконуваної програми на етапі компіляції (у Microsoft Windows такі файли мають розширення .lib, у UNIX-подібніх ОС — зазвичай .a). В результаті програма включає всі необхідні функції, що робить її автономною, але збільшує розмір.

Динамічні бібліотеки Також називаються розподілюваними бібліотеками (англ. shared library), або бібліотеками, що динамічно підключаються (англ. Dynamic Link Library, DLL). Це окремі файли, що надають програмі набір використовуваних функцій для завантажування на етапі виконання при зверненні програми до ОС із заявкою на виконання функції з бібліотеки. Якщо необхідна бібліотека вже завантажена в оперативну пам'ять, програма використуватиме завантажену копію бібліотеки. Такий підхід дозволяє зекономити час і пам'ять, оскільки декілька програм використовують одну копію бібліотеки, вже завантажену в пам'ять.

Динамічні бібліотеки зберігаються зазвичай у визначеному місці й мають стандартне розширення. Наприклад, файли .library у логічному томі Libs: у AmigaOS; у Microsoft Windows і OS/2 файли бібліотек загального користування мають розширення .dll; у UNIX-подібних ОС — зазвичай .so; у MacOS — .dylib.

З зошита»»»»»

Утиліта для управління статичними бібліотеками – ar.

Заходимо в каталог ~/SPOS/clib/exemple.1

1-й стан – відкомпілювати створений об’єктний файл

gcc –c test1.c test2.c

2) об’єднаємо наші об’єктні файли arc r libtest.a test1.o test2.o library.a(назва бібліотеки)

3) з файлу app.c також робимо об’єктний файл

gcc –c app.c => app.o

Статичну бібліотеку можна підключити до програми, напр. за допомогою опції ltest компілятора gcc

4) скомпонувати бібліотеку: виконуваний файл

gcc –o app app.o –L. –ltest

–L. – вказує, як бібліотеку потрібно шукати в поточному каталозі.

Результат – утворення виконуваного файлу ./app

Для того щоб створити дин.звязану бібл.. треба спеціальним чином скомпонувати її складові об’єктні файли

gcc –c –fPIC test1.c test2.c

–fPIC - для компіляції об’єктних файлів

2) gcc –c app.c => app.o - робимо обєктний файл з application.c

3) gcc –shared –fPIC –o libtest.so test1.o test2.o компоновка

–shared – опція викор для створення дин.звяз.бібл.

4) gcc –o app app.o –L. –ltest – не запуститься, бо не знає де знайти бібліотеку. Тому ми надаємо змінній оточення певне значення, а саме наш поточний каталог(.)

export LD_LIBRARY_PATH=.

echo $ LD_LIBRARY_PATH

52. Види бібліотек та порядок створення бібліотек.

Бібліотека — збірка об'єктів чи підпрограм для вирішення близьких за тематикою задач. Бібліотеки містять первинний код та дані, допоміжні для задіяння та інтеграції нових можливостей в програмні рішення.

Бібліотека може означати те саме, що модуль, або декілька модулів.

З точки зору комп'ютерних наук бібліотеки діляться на статичні та динамічні.

Статичні бібліотеки можуть бути у вигляді початкового тексту, що підключається програмістом до своєї програми на етапі написання (наприклад, для мови Fortran існує величезна кількість бібліотек для вирішення різних завдань саме в початкових текстах), або у вигляді об'єктних файлів, що приєднуються (лінкуються) до виконуваної програми на етапі компіляції (у Microsoft Windows такі файли мають розширення .lib, у UNIX-подібніх ОС — зазвичай .a). В результаті програма включає всі необхідні функції, що робить її автономною, але збільшує розмір.

Динамічні бібліотеки Також називаються розподілюваними бібліотеками (англ. shared library), або бібліотеками, що динамічно підключаються (англ. Dynamic Link Library, DLL). Це окремі файли, що надають програмі набір використовуваних функцій для завантажування на етапі виконання при зверненні програми до ОС із заявкою на виконання функції з бібліотеки. Якщо необхідна бібліотека вже завантажена в оперативну пам'ять, програма використуватиме завантажену копію бібліотеки. Такий підхід дозволяє зекономити час і пам'ять, оскільки декілька програм використовують одну копію бібліотеки, вже завантажену в пам'ять.

Динамічні бібліотеки зберігаються зазвичай у визначеному місці й мають стандартне розширення. Наприклад, файли .library у логічному томі Libs: у AmigaOS; у Microsoft Windows і OS/2 файли бібліотек загального користування мають розширення .dll; у UNIX-подібних ОС — зазвичай .so; у MacOS — .dylib.

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

53. Поняття файлу та файлової системи. Імена файлів. Символічне посилання на файл.

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

Фа́йлова систе́ма — спосіб організації даних, який використовується операційною системою для збереження інформації у вигляді файлів на носіях інформації. Також цим поняттям позначають сукупність файлів та директорій, які розміщуються на логічному або фізичному пристрої.

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

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

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

Символічні посилання існують завдяки тому, що вони долають кілька обмежень, властивих для (“жорстких”) посилань:

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

· Ви не можете створити посилання на каталоги, щоб уникнути створення циклів в файловій системі. Але можете створити симлінк, який вказує на каталог, і використовувати його так, якби це насправді був каталог.

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

54. Фізична організація файлових систем. Типи фізичної організації файлових систем. Поняття фрагментації даних.

Поняття фрагментації даних.

Основні критерії ефективності фізичної організації файлу:

 швидкість доступу до даних;

 об'єм адресної інформації файлу;

 ступінь фрагментованості дискового простору;

 можливість збільшення розміру файлу.

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

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

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

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

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

55. Типи файлів. Власники файлів. Права доступу до файлів.

В UNIX існують 6 типів файлів, що розрізняються за функціональним

призначенням та діям операційної системи при виконанні тих чи

інших операцій над файлами:

1. Звичайний файл (regular file)

2. Каталог (directory)

3. Спеціальний файл пристрою (special device file)

4. FIFO або іменований канал (named pipe)

5. Зв'язок (link)

6. Сокет

UNIX - багатокористувацька система. Щоб захистити файли кожного користувача від впливу інших

користувачів, UNIX підтримує механізм, відомий, як система прав доступу до файлів.

Файли в UNIX мають двох власників: користувача (user owner) і групу

(group owner). Важливою особливістю є те, що власник-користувач може не бути членом групи, що володіє файлом.

Власником-користувачем новоствореного файлу є користувач,

який створив файл.

Системний адміністратор може дати користувачу доступ більш, ніж до однієї групи.

Групи звичайно визначаються типами користувачів даної машини.

Права доступу підрозділяються на три типи: читання (read), запис (write) і виконання (execute). Ці типи прав

доступу можуть бути надані трьом класам користувачів: власнику файлу, групі, у котру входять власник, і усім

(іншим) користувачам.

Дозвіл на читання дозволяє користувачу читати уміст файлів, а у випадку каталогів - переглядати перелік імен

файлів у каталозі (використовуючи, наприклад, ls). Дозвіл на запис дозволяє користувачу писати у файл і змінювати його. Для каталогів це надає право створювати в каталозі нові файли і каталоги, чи видаляти файли в цьому каталозі.

Нарешті, дозвіл на виконання дозволяє користувачу виконувати файли (як бінарні програми, так і командні файли).

Дозвіл на виконання стосовно до каталогів означає можливість виконувати команди начебто cd.

56. Основні атрибути файлів.

Атрибути - це характеристики властивостей файлів. Зазвичай має такі атрибути:

1) Час створення

2) Розмір

3) Дата встановленої модифікації

4) Права доступу

Специфічно для UNIX систем:

1) тип файлу(6 типів)

2) розмір

3) права доступу

4) ідентифікатор власника користувача

5) ід. Групи власника

6) час останньої модифікації

існує ще 4 додаткових:

1) ознака примусового блокування

2) ознака липкості

3) SUID(set user ID)

4) GUID(get user ID)

Для виконуваних файлів ознака липкості вказує на те, що необхідно зберегти образ файлу в пам’яті після його виконання.

57. Призначення та приклади використання утиліт: mkdir, mknod, mkfifo, cp, mv, rename.