Для чего нужен "ln -L" (--logical)?

Я могу прочитать на странице man ln:

   -L, --logical
          make hard links to symbolic link references

Я где-то читал, что ln -L можно использовать для повторного связывания удаленных, но открытых файлов, используя /proc файловая система. Например:

ln -L /proc/1234/fd/12 /tmp/my-file

Но я получаю ENOENT: Данный файл или каталог отсутствует. Если я попытаюсь использовать другую файловую систему, вместо этого я получу неверную ссылку для нескольких устройств.

Если я не могу использовать ln -L чтобы восстановить удаленные файлы, тогда для чего они могут быть использованы?

Источник

2 ответа

Решение

Утилиты GNU в основном документированы info страницы. На информационной странице GNU:

‘-L’
‘--logical’
    If -s is not in effect, and the source file is a symbolic link,
    create the hard link to the file referred to by the symbolic link,
    rather than the symbolic link itself.

Так что это просто разыменовывает символические ссылки в качестве исходных аргументов.

Источник

Ну, немного более дружественный для новичка ответ...

Некоторые основы заранее

Простое представление о том, как файлы хранятся в системах UNIX/Linux: Есть запись в каталоге, состоящая из имени, которое вы видите с помощью ls -l, и номера Inode (вы можете увидеть с помощью ls -i). Inode содержит фактическую информацию о том, где ваши данные хранятся в файловой системе (среди прочего, такие как владение, права доступа, дополнительные Inodes при необходимости и т. Д.):

(Время для UTF-8 веселья...;-))

Простой вид:

┌─────────────────┐    ┌───────┐    ┌─────────────┐
│ directory entry │ ─► │ Inode │ ─► │ data blocks │
└─────────────────┘    └───────┘    └─────────────┘

Теперь о разнице между жесткой и символической ссылкой:

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

  • Жесткие ссылки на один и тот же файл не могут иметь разные права доступа к файлу (так как они хранятся в Inode)
  • Жесткие ссылки должны находиться в одной файловой системе

Расширенный простой вид

 ┌─────────────────┐   
 │    hard link    │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │  example_file   │ ─► │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │  symbolic link  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Теперь вернемся к -L вариант с -s отсутствует: позволяет создать жесткую ссылку на файл, на который указывает символическая ссылка (например, "жесткая ссылка" в примере выше).

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

Ну, поведение этого, безусловно, очень зависит от реализации, и ваш пробег может варьироваться на всех платформах UNIX/Linux, но я попытаюсь объяснить, как это может работать:

Когда файл удаляется (скажем, через rm (1)), системный вызов всегда unlink (2). Он удаляет запись каталога и уменьшает счетчик ссылок (поддерживаемый в Inode) на единицу.

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

В настоящее время большинство систем UNIX поддерживают /proc иерархия файловой системы, в которой можно искать ссылки на открытые файлы, которые являются (удивительно!) символическими ссылками. Учитывая, что каждый находит правильную запись, ln -L может помочь воссоздать ссылку на inode, снова увеличив счетчик ссылок и, таким образом, не допустить удаления inode операционной системой (если счастливый пользователь достаточно быстр, и программа все еще работает).

Примечание: чтобы это работало, местоположение новой ссылки должно быть в той же файловой системе, в которой находился оригинал!

Последний пример

 ┌─────────────────┐   
 │   rescue_link   │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │ *** removed *** │    │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │ /proc/bla/fd/n  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Заключительные слова

Есть много вещей, которые могут помешать правильному созданию ссылки, и это очень зависит от того, как реализована сама символическая ссылка, и я должен признать: у меня есть серьезные сомнения, что это будет работать со многими вариантами UNIX - но, возможно, волонтер, который хочет потратить некоторое время, чтобы проверить это?

Источник
Другие вопросы по тегам