Например, у меня есть файл myold_file
. Затем я использую ln
для создания жесткой ссылки как mylink
:
ln myold_file mylink
Тогда, даже используя ls -a
, я не могу сказать, какой из них старый.
Есть что сказать?
Например, у меня есть файл myold_file
. Затем я использую ln
для создания жесткой ссылки как mylink
:
ln myold_file mylink
Тогда, даже используя ls -a
, я не могу сказать, какой из них старый.
Есть что сказать?
Ответы:
Вы не можете, потому что они в буквальном смысле один и тот же файл, только по разным путям. Первый не имеет особого статуса.
.bashrc
это файл, содержащий ...», когда мы имеем в виду, «относительный путь .bashrc
относится к файлу, содержащему ...», это обычное сочетание категорий, и мы должны понимать, что всякий раз, когда кто-то ссылается на путь или запись каталога, «являющаяся» файлом, мы имеем в виду файл, к которому он относится. При таком понимании две жесткие ссылки могут «быть» одним файлом. Отклонить эту конвенцию в пользу формального языка они не могут. Обе позиции имеют свое место :-)
Нет прямого, чистого (надежного) способа сделать это. Но при соответствующих обстоятельствах это может быть возможно (или, по крайней мере, вероятно). Проблема в том, что есть две жесткие ссылки, но только один файл. Изменения, модификации и (возможно) время создания сохраняются только для файлов (inode), но не для записей каталога (жестких ссылок). Таким образом, нужная вам информация может быть получена только из вторичных эффектов, которые могут быть легко уничтожены операциями, которые не связаны с файлом. И вы даже не можете увидеть, был ли он уничтожен. Вы можете узнать это только из оперативных обстоятельств, если точно знаете о них.
Создание жесткой ссылки - это операция записи в каталог, который содержит ссылку. Таким образом, он обновляет каталог mtime
. Так что если
ссылки находятся в разных каталогах
и вы знаете, что ни один из этих каталогов не был изменен (добавлен, удален, переименован или изменен метаданный файла) после создания второй жесткой ссылки, тогда вы можете просто сравнить mtime
s из каталогов.
Особый случай: если один из каталогов имеет mtime
предшествующий файл (inode), mtime
и вы можете быть достаточно уверены, что файл был записан не позднее, чем через короткий момент после его создания, тогда ссылка на этот каталог является более старой.
Если ссылки находятся в одном и том же каталоге (что, по-видимому, имеет место в вашем вопросе), тогда становится хуже. Тогда вы можете использовать
ls -lU
чтобы получить представление о порядке, в котором были созданы записи. Это не обязательно должен быть правильный порядок, поскольку записи могут быть удалены, чтобы новые записи создавались в середине списка каталогов. И, как отметил Жиль, он не работает с новыми файловыми системами.
ls -lU
уловка не будет работать на современных файловых системах (ext4, btrfs, zfs), там записи не отображаются в порядке создания вообще.
rm myold_file
то mylink
все равно существовали бы и работали отлично, поскольку это одинаково хорошая запись, относящаяся к тому же базовому иноду. Только после того, как оба будут удалены, система может отказаться от inode. Если для создания двух записей файловой системы, ссылающихся на один и тот же файл, используются жесткие ссылки, они становятся эквивалентными. (Обратите внимание, что здесь «файл» означает «индекс», в котором хранятся данные для файла, а не для каталога). См .: en.wikipedia.org/wiki/Inode
Если вы полагаетесь на время последнего изменения каталогов и не знаете, как и когда эти каталоги меняются, то, полагаясь на mtime, вы в какой-то момент времени будете ошибаться. Проблема здесь в том, что файл представлен в файловой системе индексом, а не записью каталога. Запись каталога (имя файла) указывает на индекс, а не на файл.
Я думаю, что я буду делать некоторые пуповинные размышления о том, почему мне нужно знать, какая запись каталога старше и как избежать необходимости знать это.
Я думаю, что этот вопрос (вполне обоснованно) ошибочен относительно того, что на самом деле является жесткой ссылкой. Я думаю, однако, самый правильный прямой ответ: «Они оба» .
Файловые системы Unix обычно хранят фактическое содержимое файла и данные в i-узлах, они вообще не имеют пути, тогда пути имеют отношение «много-к-одному» к этим i-узлам. Возьмите в качестве аналогии человека, который носит два имени, Боб и Джо. Нельзя сказать, что Боб старше Джо или наоборот, это просто имена одного и того же человека.
Если вы хотите сохранить концепцию «оригинального» файла и нового, который вы, скорее всего, ищете вместо символической ссылки, это скорее псевдоним, просто инструкция ОС, что он должен работать с одним путем, как будто они были к другому без изменения структуры файла под. (Вы можете сделать это с помощью "ln -s file link".
Суть ответа, данного несколькими другими выше, заключается в том, что каждое имя файла является жесткой ссылкой на файл. Нет настоящего оригинала, возможно, только первый.
Думайте о каталоге как о таблице, в которой перечислены имена файлов и номера inode.
Каждая жесткая ссылка, включая первую, представляет собой запись в каталоге, которая присваивает «имя файла» номеру индекса, чтобы вы могли получить доступ к файлу по этому имени.
Файл представляет собой набор блоков на диске, управляемый и отслеживаемый метаданными, хранящимися в inode. Файл имеет один номер индекса.
Доступ к данным файла через имя файла состоит из трех этапов: имя файла ищется в каталоге для получения номера индекса. Затем к индексу обращаются, чтобы найти соответствующий блок диска (или блоки), содержащий данные. Затем, наконец, эти блоки читаются / записываются.
Итак, вернемся ко всему, что в основном заключается в следующем: нет абсолютно никакой разницы между доступом к содержимому файла с использованием первой («оригинальной») или любых впоследствии созданных жестких ссылок.
ls > a; ln a b; rm a; ln b c
, то какой из них «более оригинальный», чем другой?a
нет, вы остались сb
иc
...