Как определить, какой файл является оригинальным, если создана жесткая ссылка


34

Например, у меня есть файл myold_file. Затем я использую lnдля создания жесткой ссылки как mylink:

ln myold_file mylink

Тогда, даже используя ls -a, я не могу сказать, какой из них старый.

Есть что сказать?


2
Встречный вопрос: если так ls > a; ln a b; rm a; ln b c, то какой из них «более оригинальный», чем другой? aнет, вы остались с bи c...
glglgl

2
Чего ты пытаешься достичь? Чего ты пытаешься достичь? Там нет «оригинал» как таковой. Файл - это индекс, содержащий метаданные и набор блоков, содержащих данные. Каталог может содержать ссылку на файл, и эта ссылка представляет собой имя файла и номер индекса. Вы можете создать любое количество ссылок на файл. Файлы не могут содержать менее одной ссылки.
Йохан

Для подробного объяснения принятого ответа на этот вопрос: см. Принятый ответ на этот вопрос .
Утку

Ответы:


93

Вы не можете, потому что они в буквальном смысле один и тот же файл, только по разным путям. Первый не имеет особого статуса.


4
Это, безусловно, правильный ответ: вопрос ОП основан на недоразумении.
Даниэль Уорвикер

8
@Adnan На самом деле нет: две жесткие ссылки - это один и тот же файл. Это разные записи каталога. Терминология Дженни Ди верна.
Жиль "ТАК - перестать быть злым"

1
@ Жиль, я не понимаю, как это можно исправить. Две жесткие ссылки - это не два файла ; жесткие ссылки не являются файлами. Они указывают , следовательно, ссылку , на тот же файл (который является физическим местоположением на диске). Сказать, что «две жесткие ссылки - это буквально один и тот же файл» - неправильно.
Ади

1
@JennyD И это единственный способ услышать, как используется «жесткая ссылка»; указатель файловой системы на индекс. Ну, я думаю, мы все не правы и правы. Я перестану спорить об этом, так как это бессмысленно. Ваш ответ мне кажется правильным, у вас есть +1 от меня, и я оставлю это на этом.
Ади

5
Сказать, что жесткая ссылка «это» файл, сравнивает вещи разных категорий, что технически неверно. Но, учитывая, что мы обычно говорим, « .bashrcэто файл, содержащий ...», когда мы имеем в виду, «относительный путь .bashrcотносится к файлу, содержащему ...», это обычное сочетание категорий, и мы должны понимать, что всякий раз, когда кто-то ссылается на путь или запись каталога, «являющаяся» файлом, мы имеем в виду файл, к которому он относится. При таком понимании две жесткие ссылки могут «быть» одним файлом. Отклонить эту конвенцию в пользу формального языка они не могут. Обе позиции имеют свое место :-)
Стив Джессоп

16

Нет прямого, чистого (надежного) способа сделать это. Но при соответствующих обстоятельствах это может быть возможно (или, по крайней мере, вероятно). Проблема в том, что есть две жесткие ссылки, но только один файл. Изменения, модификации и (возможно) время создания сохраняются только для файлов (inode), но не для записей каталога (жестких ссылок). Таким образом, нужная вам информация может быть получена только из вторичных эффектов, которые могут быть легко уничтожены операциями, которые не связаны с файлом. И вы даже не можете увидеть, был ли он уничтожен. Вы можете узнать это только из оперативных обстоятельств, если точно знаете о них.

Создание жесткой ссылки - это операция записи в каталог, который содержит ссылку. Таким образом, он обновляет каталог mtime. Так что если

  1. ссылки находятся в разных каталогах

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

Особый случай: если один из каталогов имеет mtime предшествующий файл (inode), mtimeи вы можете быть достаточно уверены, что файл был записан не позднее, чем через короткий момент после его создания, тогда ссылка на этот каталог является более старой.

Если ссылки находятся в одном и том же каталоге (что, по-видимому, имеет место в вашем вопросе), тогда становится хуже. Тогда вы можете использовать

ls -lU

чтобы получить представление о порядке, в котором были созданы записи. Это не обязательно должен быть правильный порядок, поскольку записи могут быть удалены, чтобы новые записи создавались в середине списка каталогов. И, как отметил Жиль, он не работает с новыми файловыми системами.


2
Нет упоминаний о selinux, контрольных журналах или слежке за журналом файловой системы ??? ухмылка Без контрольного следа нет никакого способа узнать - все остальное - расчетное предположение
Рикки Бим

1
@mikeserv Если вы хотите учить других таким образом, вы должны хотя бы научиться правильно цитировать. В вопросе не указано «какой файл». И даже если бы это произошло, тогда это была бы просто проблема формулировки, и если бы кто-то задумался над этим вопросом, то легко мог бы понять, о чем он на самом деле.
Хауке Лагинг

4
Справочник mtime трюк будет работать, если обстоятельства верны (что редко). Однако, как вы это представляете, вы иногда приходите к противоположному выводу. Каталог mtime полезен только в том случае, если он равен ctime файла. Но ls -lUуловка не будет работать на современных файловых системах (ext4, btrfs, zfs), там записи не отображаются в порядке создания вообще.
Жиль "ТАК - перестань быть злым"

2
@mikeserv - вопрос ОП основан на недоразумении. Если бы они существовали, rm myold_fileто mylinkвсе равно существовали бы и работали отлично, поскольку это одинаково хорошая запись, относящаяся к тому же базовому иноду. Только после того, как оба будут удалены, система может отказаться от inode. Если для создания двух записей файловой системы, ссылающихся на один и тот же файл, используются жесткие ссылки, они становятся эквивалентными. (Обратите внимание, что здесь «файл» означает «индекс», в котором хранятся данные для файла, а не для каталога). См .: en.wikipedia.org/wiki/Inode
Daniel Earwicker

1
-1 потому что, хотя информация об изменении каталога в некоторых файловых системах при обновлении таблиц, этот ответ не может прояснить недоразумение, присутствующее в вопросе о том, что «оригинальный файл» не является свойством в случае нескольких жестких ссылок в один инод. В этом смысле, хотя в анекдотическом смысле это интересно, не то, что большинству людей, обсуждающих этот вопрос, следует узнать о фундаментальной концепции жестких ссылок. Эта проблема не в отсутствии «прямого чистого способа сделать это», проблема в том, что в первую очередь нет «этого» .
Калеб

10

Если вы полагаетесь на время последнего изменения каталогов и не знаете, как и когда эти каталоги меняются, то, полагаясь на mtime, вы в какой-то момент времени будете ошибаться. Проблема здесь в том, что файл представлен в файловой системе индексом, а не записью каталога. Запись каталога (имя файла) указывает на индекс, а не на файл.

Я думаю, что я буду делать некоторые пуповинные размышления о том, почему мне нужно знать, какая запись каталога старше и как избежать необходимости знать это.


8

Я думаю, что этот вопрос (вполне обоснованно) ошибочен относительно того, что на самом деле является жесткой ссылкой. Я думаю, однако, самый правильный прямой ответ: «Они оба» .

Файловые системы Unix обычно хранят фактическое содержимое файла и данные в i-узлах, они вообще не имеют пути, тогда пути имеют отношение «много-к-одному» к этим i-узлам. Возьмите в качестве аналогии человека, который носит два имени, Боб и Джо. Нельзя сказать, что Боб старше Джо или наоборот, это просто имена одного и того же человека.

Если вы хотите сохранить концепцию «оригинального» файла и нового, который вы, скорее всего, ищете вместо символической ссылки, это скорее псевдоним, просто инструкция ОС, что он должен работать с одним путем, как будто они были к другому без изменения структуры файла под. (Вы можете сделать это с помощью "ln -s file link".


Вы знаете, Боб / Джо может быть очень чувствителен к своему возрасту ... Сравнение жестких и мягких ссылок является хорошим, особенно если учесть, что жесткая ссылка просто добавит запись в файл каталога - уже существующую inode - но программная ссылка - это файл сам по себе, и поэтому ему присваивается свой собственный inode. Тем не менее, в обоих случаях время модификации относится только к связанному файлу, поскольку единственными изменениями, которые могут быть сделаны для ссылки любого значения, будет только создание / удаление.
mikeserv

2

Суть ответа, данного несколькими другими выше, заключается в том, что каждое имя файла является жесткой ссылкой на файл. Нет настоящего оригинала, возможно, только первый.

Думайте о каталоге как о таблице, в которой перечислены имена файлов и номера inode.

Каждая жесткая ссылка, включая первую, представляет собой запись в каталоге, которая присваивает «имя файла» номеру индекса, чтобы вы могли получить доступ к файлу по этому имени.

Файл представляет собой набор блоков на диске, управляемый и отслеживаемый метаданными, хранящимися в inode. Файл имеет один номер индекса.

Доступ к данным файла через имя файла состоит из трех этапов: имя файла ищется в каталоге для получения номера индекса. Затем к индексу обращаются, чтобы найти соответствующий блок диска (или блоки), содержащий данные. Затем, наконец, эти блоки читаются / записываются.

Итак, вернемся ко всему, что в основном заключается в следующем: нет абсолютно никакой разницы между доступом к содержимому файла с использованием первой («оригинальной») или любых впоследствии созданных жестких ссылок.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.