Почему жесткие ссылки занимают то же место, что и оригиналы?


14

Благодаря некоторым хорошим вопросам и ответам здесь и на этой странице , теперь я понимаю ссылки. Я вижу, что жесткие ссылки ссылаются на один и тот же inode под другим именем, а копии - это разные "узлы с разными именами. Плюс к этому soft-ссылки имеют исходное имя файла и путь в качестве своего 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

Я обнаружил, что неудобно, что жесткая ссылка имеет тот же размер, что и оригинал и, по логике, копия. Если жесткая ссылка и оригинал имеют один и тот же индекс, который содержит данные и отличаются только по имени файла, не должна ли жесткая ссылка занять только пространство своего имени вместо 205 байтов? Или это размер исходного файла, который ls -lhвозвращается? Но тогда как я могу узнать, какое место занимает имя файла? Здесь говорится, что жесткие ссылки не имеют размера. Имя их файла хранится вместе с исходным именем файла? Где хранится имя файла жестких ссылок?

Ответы:


16

Файл - это индекс с метаданными, среди которых список указателей, где найти данные.

Чтобы получить доступ к файлу, необходимо связать его с каталогом (представьте каталоги как телефонные каталоги, а не папки), то есть добавьте одну или несколько записей в один из нескольких каталогов, чтобы связать имя с этим файлом.

Все эти ссылки, эти имена файлов указывают на один и тот же файл. Нет ни одного оригинала, а других ссылок. Все они являются точками доступа к одному и тому же файлу (одному и тому же узлу) в дереве каталогов. Когда вы получаете размер файла ( lstatсистемный вызов), вы извлекаете информацию (эти метаданные, упомянутые выше), хранящиеся в 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. То есть вы не удаляете файлы, вы отсоединяете их от каталогов, на которые они ссылаются. После того, как вы отменили связь с последним каталогом, в котором была запись в данный файл, этот файл затем уничтожается (если его нет у процесса) открыт).


Ааа ... Теперь я вижу. Таким образом, файл с именем «hi» и его точная копия с именем «ajhĝjdmjefsjmksgskgjkmŝŭna» занимают точно такой же объем пространства; потому что их имена не учитываются для того lstatсистемного вызова, который получает их размер.
JMCF125

@ JMCF125, да, размер их имен - это запись в соответствующих каталогах, она учитывается в размере файлов каталогов.
Стефан Шазелас

Благодарю. Можете ли вы включить это в свой ответ? Подождите, я сначала уточню свой вопрос.
JMCF125

5

Жесткая ссылка, по сути, оригинальный файл. Таким образом, сообщаемый вами размер равен размеру файла, на который идет ссылка. Это мягкие ссылки, которые занимают только пространство их имен (вроде).

Что касается файловой системы, то жесткая ссылка и оригинал - это одно и то же, они указывают на один и тот же индекс, поэтому сообщается об одном и том же размере.


Но имя жесткой ссылки должно занимать место, правильно?
JMCF125

Смотрите ответ @ stephan ниже, он объясняет это лучше.
Terdon

2
@ JMCF125 Да, но это пространство находится внутри каталога. Если вы создадите достаточно файлов, вы заметите, что размеры каталогов увеличиваются. Размер файла не включает его метаданные, такие как имя.
Жиль "ТАК - перестань быть злым"

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