Чому, здається, жорсткі посилання займають таке ж місце, як і оригінали?


14

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

Отже, я перевірив те, що я дізнався з деяким файлом ("saluton_mondo.cpp" нижче), зробив твердий і м'який посилання та копію.

jmcf125@VMUbuntu:~$ ls -lh soft hard copy s*.cpp
-rw-rw-r-- 1 jmcf125 jmcf125 205 Aŭg 27 16:10 copy
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 hard
-rw-rw-r-- 2 jmcf125 jmcf125 205 Aŭg 25 13:34 saluton_mondo.cpp
lrwxrwxrwx 1 jmcf125 jmcf125  17 Aŭg 27 16:09 soft -> saluton_mondo.cpp

Мені було незручно, що жорстке посилання має однаковий розмір, як оригінал, і, логічно, копія. Якщо жорстке посилання та оригінал мають один і той самий inode, у якого є дані, і відрізняються лише іменем файлу, чи не повинен жорсткий посилання займати лише пробіл свого імені, а не 205 байт? Або це розмір вихідного файлу, який ls -lhповертається? Але як я можу знати, який простір займає ім'я файлу? Тут сказано, що жорсткі посилання не мають розміру. Чи ім'я файлу зберігається поряд із початковим ім'ям файлу? Де зберігається ім'я файлу жорстких посилань?

Відповіді:


17

Файл - це inode з метаданими, серед яких список покажчиків на те, де знайти дані.

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

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

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

$ touch a
$ ln a b
$ ln -s a c
$ ln c d
$ ls -li [a-d]
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 a
10486707 -rw-r--r-- 2 stephane stephane 0 Aug 27 17:05 b
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 c -> a
10502404 lrwxrwxrwx 2 stephane stephane 1 Aug 27 17:05 d -> a

Над номером файлу 10486707 - звичайний файл. На нього посилаються два записи в поточному каталозі (один з ім'ям a, один з ім'ям b). Оскільки кількість посилань становить 2, ми знаємо, що в поточному каталозі чи в будь-якому іншому каталозі іншого імені цього файлу немає. Номер файлу 10502404 - це ще один файл, цей час типу символьного посилання, пов'язаного двічі до поточного каталогу. Його зміст (ціль) - відносний шлях "а".

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

$ mkdir 1 2
$ echo foo > 1/a
$ echo bar > 2/a
$ ln -s a 1/b
$ ln 1/b 2/b
$ ls -lia 1 2
1:
total 92
10608644 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10504186 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a

2:
total 92
10608674 drwxr-xr-x   2 stephane stephane  4096 Aug 27 17:26 ./
10485761 drwxrwxr-x 443 stephane stephane 81920 Aug 27 17:26 ../
10539044 -rw-r--r--   1 stephane stephane     4 Aug 27 17:24 a
10539259 lrwxrwxrwx   2 stephane stephane     1 Aug 27 17:26 b -> a
$ cat 1/b
foo
$ cat 2/b
bar

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

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


Ааа ... Тепер я бачу. Таким чином, файл під назвою "привіт" і його точна копія під назвою "ajhĝjdmjefsjmksgsgskgjkmŝŭna" займають точно таку ж кількість простору; тому що їхні імена не враховуються для цього lstatсистемного виклику, який набуває їх розміру.
JMCF125

@ JMCF125, так, розмір, прийнятий за їх іменами, є записом у відповідних каталогах, він враховується у розмірі файлів каталогів.
Стефан Шазелас

Спасибі. Чи можете ви включити це у свою відповідь? Зачекайте, спочатку я уточню своє питання.
JMCF125

5

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

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


Але ім'я жорсткого посилання має займати місце, правильно?
JMCF125

Дивіться відповідь @ Стефана нижче, він пояснює це краще.
terdon

2
@ JMCF125 Так, але цей простір знаходиться всередині каталогу. Якщо ви створите достатньо файлів, ви помітите, що розміри каталогів збільшуються. Розмір файлу не включає його метаданих, таких як його ім'я.
Жил "SO- перестань бути злим"

@Gilles, дякую, але @Stephane вже оновив свою відповідь на цю інформацію. Крім того, тепер я думаю про це краще, ім’я /повинне зберігатися в собі, як ніби ви cd ..в ньому /залишаєтесь /.
JMCF125
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.