Навіщо зберігати посилання "власне та батьківське" (. І ..) у записі каталогу?

Розглянемо файлову систему, націлену на деякі вбудовані пристрої, яка робить не більше, ніж зберігає файли в структурі ієрархічної директорії. У цій файловій системі бракує багатьох операцій, до яких ви можете використовуватись у таких системах, як Unix та Windows (наприклад, дозволи на її доступ є абсолютно різними і не прив’язані до метаданих, що зберігаються в каталогах). Ця файлова система не допускає будь-якого жорсткого посилання або м'якого посилання, тому кожен файл має унікальне ім’я в строгій структурі дерева.

Чи є якась користь для зберігання посилання на саму директорію та на її батьківську в структурі даних на диску, що представляє каталог?

Більшість файлових систем Unix мають .і ..записи на диску. Цікаво, чому вони не обробляють ті, на рівні VFS (загальний драйвер файлової системи). Це історичний артефакт? Чи є вагомі причини, і якщо так, то саме, щоб я міг визначити, чи відповідає вона моїй вбудованій системі?

Мати посилання на батьківський каталог має для мене сенс. Якби у вас їх не було, вам завжди потрібно було б працювати з цілим списком каталогів. Так, наприклад, /home/svick/Documents/треба було б представити як { /, /home/, /home/svick/, /home/svick/Documents }. Якщо ви цього не зробили, ви б взагалі не змогли знайти батьківський каталог (або це було б дуже дорого). Це не тільки неефективно, але й небезпечно. Якщо у вас є два таких списки, які перекриваються, вони можуть легко десинхронізуватися, якщо ви перемістите деякий каталог.

З іншого боку, якщо у вас є посилання на батьківський каталог, це більш ефективно та безпечніше.

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

У вас виходить менше спеціальних випадків. У багатьох ситуаціях VFS може обробляти ".." так, як він обробляє будь-яке інше ім'я каталогу.

Єдиною причиною, яку я можу уявити, є такий сценарій:

1. Оригінальна реалізація файлової системи існувала з тим самим форматом каталогів, але поняття файлових шляхів та підкаталогів тоді не розглядалися (див . Файлову систему PDP-7 Unix ).

2. Тоді люди думали, що розв’язання шляхів та підкаталоги будуть корисними!

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

То, може, ми залишилися з цими марними артефактами, просто задля відсталої сумісності з 40-річним програмним забезпеченням? Надійний сценарій?

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

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

Що стосується загальної потреби .та ..як би ви виражали відносні шляхи без них? Принаймні, ..він незамінний для шляхів, які залишають поточне піддірево. Якщо такі шляхи вам не потрібні (можливо, дерево - це примітивний спосіб кодування привілеїв доступу?), То вам не потрібні ...