Я читаю цей підручник Unix і натрапив на цю цитату ...
Тут слід зазначити, що каталог - це лише особливий тип файлу.
... але пояснення чи деталі не надаються. Як каталог справді є лише файлом?
Відповіді:
Багато об'єктів в операційній системі стилю * nix (та інших) вважаються файлами або мають визначений файловий аспект, хоча вони не обов'язково є послідовністю байтів, що зберігаються у файловій системі. Саме те, як реалізуються каталоги, залежить від типу файлової системи, але загалом те, що вони містять, розглядається як список, - це послідовність збережених байтів, тому в цьому сенсі вони не такі особливі.
Один із способів визначення того, що таке "файл" у контексті * nix, - це те, що з ним пов'язаний дескриптор файлів . Відповідно до статті wikipedia, дескриптор файлу
це абстрактний індикатор, який використовується для доступу до файлу або іншого вхідно-вихідного ресурсу , наприклад, з'єднання з трубою або мережею ...
Іншими словами, вони посилаються на різні види ресурсів, з яких / з яких може бути прочитана / записана послідовність байтів, хоча джерело / призначення цієї послідовності не визначено. По-іншому, "де" ресурсу може бути чим завгодно. Це визначає, що це канал інформації. Це частина того, чому іноді кажуть, що в unix "все - файл". Не варто це сприймати повністю буквально, але варто серйозно розглянути. Що стосується каталогу, ця інформація стосується того, що знаходиться в каталозі, а на нижчому рівні реалізації - як знайти його у файловій системі.
У цьому сенсі каталоги є начебто особливими, оскільки в рідному коді С вони ніби не асоціюються з дескриптором файлів; POSIX API використовує спеціальний тип потоку ручки, DIR*. Однак цей тип насправді має базовий дескриптор, який можна отримати . Дескриптори керуються ядром, а доступ до них завжди включає системні виклики, отже, ще одним аспектом того, що дескриптор, є те, що це канал, керований ядром ОС. Вони мають унікальні (за процес) номери, починаючи з 0, що зазвичай є дескриптором для стандартного вхідного потоку.
openat, fstatat, і т.д.) , які використовують дескриптори файлів , що належать до каталогів.
fsync()скористатися каталогом fd лише для читання (!), І він має чітко визначений ефект (конкретно, він синхронізує створення / перейменування / видалення файлів у даному каталозі на диск, теоретично необхідний крок "написати" у тимчасовий файл і перейменувати його на оригінальний "ідіома".
У Unix спосіб робити речі: все є файлом.
Каталог - це один (з багатьох) тип спеціального файлу. Він не містить даних. Натомість він містить вказівники на всі файли, що містяться в каталозі.
Інші типи спеціальних файлів:
Але оскільки вони вважаються "файлами", ви можете lsїх перейменовувати та переміщувати та, залежно від типу спеціального файлу, надсилати дані в / з них.
Моя відповідь - це просто ремінісценція, але в 199x старовинних Unixes, яких було багато, каталоги були файлами, просто поміченими "каталогом" десь у дисковій inode.
Ви можете відкрити каталог з чимось на зразок open(".", O_RDONLY)і отримати дескриптор файлу, який можна використовувати. Ви можете проаналізувати вміст, якщо прокручуєте /usr/includeта знайшли правильне визначення структури С. Я знаю, що я робив це для систем SunOS 4.1.x, файлової системи SGS EFI і будь-яких робочих станцій Mips-CPU DEC для файлової системи, ймовірно, BSD4.2 FFS.
Це був поганий досвід. Стандартизація на рівні віртуальної файлової системи - хороша річ для портативності, навіть якщо каталоги вже не є строгими файлами. Шари VFS дозволяють нам експериментувати з файловими системами, де каталоги не є файлами, як ReiserFS або NFS.
cp --link dir1/* dir2, хоча я не впевнений у його зручності.
Каталог особливий тим, що він має "d" у своєму режимі, кажучи файловій системі, що він повинен інтерпретувати його вміст як перелік інших файлів, що містяться в каталозі, а не як звичайний файл, який є лише послідовністю байтів. читати в додатку. Це все.
Довідники - це файли, оскільки в Linux працюють системи універсальну модель вводу-виводу . У моделі все в системі є файлом, і до нього можна отримати доступ з тими ж системними викликами та різними командами.
Вони мають особливий тип, оскільки їх i-вузли мають позначку для типу файлу, і вони мають особливу структуру, що є таблицею імен файлів і посилань на інші i-вузли. Ці пари імен файлових посилань, також відомі як "жорсткі посилання", в i-вузлі каталогу перераховують файли "всередині" каталогу.
Каталоги призначені лише для організації файлів. Коли файл "переміщується" з каталогу в інший, сам файл не переселяється на диск. Просто запис у одному i-вузлі каталогу видаляється та записується в інший каталог i-node.
Прийнята відповідь не зовсім коректна. в системах POSIX "Inodes" вказують на файли та каталоги. Дескриптори файлів унікальні лише для процесу, а не для системи. Однак, узори є унікальними, хоча більше одного входу може вказувати на один файл. Прокоментував би прийняту відповідь, але не зміг через обмеження повторення.
ls -l >test.txt;ln -vf test.txt test2.txt;ls -li test.txt test2.txt. Отже, ви побачите, що жорсткі посилання мають однаковий номер inode.
fork()s, його дочірній процес матиме (за винятком якихось особливих обставин, а саме O_CLOEXECпрапор) точно такі ж сутності файлів-сценаристів, що і оригінальний процес. Інший приклад: дочірні процеси apache виконуються listen()на тому самому дескрипторі файлу сокета. Але ця відповідь стосується не дескрипторів файлів, які є внутрішньою структурою даних і є лише в пам'яті ядра. Ця ( помилкова ) відповідь стосується записів каталогів та індексів, це дискові об'єкти (тобто вони є фізичними байтами на жорсткому диску).
fork()трапиться, а потім дочірній процес seek()або close()s, це не вплине на дескриптор файлу батьків. Тому я зараз думаю, що дескриптори файлів є лише частково структурно-приватними структурами. Але це питання не стосується них, це питання про батьків / індесів, і я коментую вам абсолютно неправдиву відповідь на це питання.