Ну, немного более дружественный для новичка ответ ...
Некоторые основы заранее
Простое представление о том, как файлы хранятся в системах UNIX/Linux: Есть запись в каталоге, состоящая из имени, которое вы видите с помощью ls -l и номера Inode (вы можете увидеть с помощью ls -i). Inode содержит фактическую информацию о том, где ваши данные хранятся в файловой системе (среди прочего, такие как владение, права доступа, дополнительные Inode, если это необходимо, и т.д.):
(Время для 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 может помочь воссоздать ссылку на индекс, снова увеличив счетчик ссылок и, таким образом, предотвратить удаление индекса операционной системой (если удачливый пользователь достаточно быстр, и программа все еще работает),
Примечание: чтобы это работало, местоположение новой ссылки должно быть в той же файловой системе, в которой находился оригинал!
Последний пример
┌─────────────────┐
│ rescue_link │ ───────┐
└─────────────────┘ ▼
┌─────────────────┐ ┌───────┐ ┌─────────────┐
│ *** removed *** │ │ Inode │ ─► │ data blocks │
└─────────────────┘ └───────┘ └─────────────┘
▲
└───────────────────────┐
│
┌─────────────────┐ ┌─────────┴──────────┐
│ /proc/bla/fd/n │ ─► │ filename reference │
└─────────────────┘ └────────────────────┘
Заключительные слова
Есть много вещей, которые могут помешать правильному созданию ссылки, и это очень зависит от того, как реализована сама символическая ссылка, и я должен признать: у меня есть серьезные сомнения, что она будет работать со многими вариантами UNIX - но, возможно, волонтер, который хочет потратить некоторое время, чтобы проверить это?
