Коли створення жорсткого посилання було б корисним?

В основному є два основні обмеження із жорсткими посиланнями:

1. Для жорстких посилань зазвичай потрібно, щоб посилання та файл знаходилися в одній файловій системі.
2. Лише суперпользователь може створити міцне посилання на каталог.

Таким чином, символічні посилання були введені для подолання обмежень жорстких посилань. Отже, питання полягає в тому, чи потрібні ще жорсткі посилання? Чи може бути ситуація, коли вони корисніші?

Жорсткі посилання допомагають нам організувати нашу файлову систему набагато більш гнучко. В основному, жорсткі посилання дозволяють нам взяти один файл і мати його кілька місць у файловій системі одночасно. Подумайте про сценарій, коли ви фотограф і маєте багато фотографій (це приклад з мого життя!). Ви можете організувати їх людьми, які з’являються в них, тому що іноді люди просять вас їх фотографії. Але ви також можете впорядкувати їх за місцем розташування та за датою. Немає реального способу гніздування цих трьох речей, вони абсолютно окремі осі організації. Таким чином, ви можете створити три різні ієрархії для цих трьох різних речей, і кожна фотографія присутня у всіх трьох, без нихпотрібно зберігати кожну фотографію три рази. Це магія твердих посилань. Від’єднавши посилання, нам не потрібно турбуватися про те, де "справжній файл", тому що всі вони є реальним файлом. Ми можемо видалити та переміщувати за бажанням, оскільки файл буде зберігатися до тих пір, поки на нього більше не буде посилань, та видалиться, коли ви видалите останнє жорстке посилання. Це просто і не вимагає від вас дуже багато слідкувати.

Вміст файлу не буде очищено, поки всі жорсткі посилання (так, усі назви файлів - це жорсткі посилання, навіть перше) не будуть стерті та файл закритий. Таким чином , це може бути корисно , коли потрібно файл в декількох місцях, але може бути віддалене від будь-якого з них в будь-який час, наприклад , між ~/Downloads/coolsong.mp3і ~/Music/Cool Song.mp3.

Однією не дуже важливою перевагою жорсткого посилання над символічним посиланням є те, що, коли воно доходить до inode для жорсткого посилання, ядро ​​не потребує додаткової обробки для доступу до файлу. Коли воно стикається з символічним посиланням, ядро ​​повинно прочитати значення посилання та продовжити обхід структури каталогів, перш ніж потрапити до inode для файлу. Це займає більше часу, хоча різницю не обов'язково легко виміряти. Це стає дійсно весело, коли один із елементів значення значення symlink є символьним посиланням.

Є кілька причин жорстких посилань

1. зберігати посилання на файл, поки не зникне остання посилання (як зазначив Ігнасіо)
2. коли ви працюєте з жорсткими файлами, вони займають лише один файл у файловій системі (обидві посилання на файл мають однакові i-вузли). Тому жорсткі посилання мають бути в одній файловій системі.

Тож одна з причин використовувати жорсткі посилання - це, можливо, заощадити багато місця ...

Ви можете додати будь-яку з посилань, і дані переходять у спільний файл. Ви також можете додати до одного дескриптора файлів під час читання з іншого (наприклад, з хвостом -f)

Багато наведених тут прикладів є дійсними, але однаково добре працюватимуть із м'якими посиланнями (наприклад, проблема "потрібен один файл у кількох місцях").

Гарний приклад того, де жорсткі посилання справді корисні, - це програмне забезпечення для резервного копіювання Dirvish :

Dirvish - це швидка мережева система резервного копіювання на основі диска.

За допомогою dirvish ви можете підтримувати набір повних зображень вашої файлової системи з без нагляду створення та закінчення терміну дії. Дервіш резервне сховище - це як машина часу для ваших даних.

Dirvish створює резервні копії на рівні файлової системи (тобто копіює файли, не створює зображень), копіюючи файли в окрему (резервну) файлову систему (наприклад, жорсткий диск USB). Кожен раз, коли ви створюєте резервну копію, dirvish створюватиме окрему, повну копію дерева каталогів, яку потрібно зберегти.

Хитрість полягає в тому, що якщо dirvish виявить, що вже є старіша резервна копія дерева, яке ви зберігаєте, воно автоматично повторно використовувати файли, які не були змінені, створивши жорстке посилання в новому дереві на файл у старому дереві.

Таким чином, кожна резервна копія - це повна, автономна копія дерева директорій, але в той же час лише змінені файли фактично займають місце у файловій системі. Іншими словами, ви отримуєте переваги додаткового резервного копіювання (економія місця) та повного резервного копіювання (простого пошуку) одночасно.

Це можливо лише тому, що жорсткі посилання повністю прозорі до інструментів простору користувачів.

Можливо, це також буде працювати з символічними посиланнями (хоча у вас виникнуть проблеми під час резервного копіювання даних, які використовують самі символічні посилання), але одна перевага можлива лише для жорстких посилань:

Якщо ви хочете викинути старі резервні копії, ви можете просто видалити відповідне дерево каталогів резервних копій. Файли, зв'язані лише з цим деревом, автоматично видаляються файловою системою (оскільки остання тверда посилання видалена), але файли, які також з'являються в інших копіях, залишаються на диску.

Один корисний випадок - скажімо, коли у вас є програма (або сценарій), якій потрібно завантажити великий тимчасовий тарбол, і після вилучення його програма негайно видалить його.

Якщо ви з якоїсь причини хочете зберегти цей тарбол для подальшого використання, найкращий шлях, ln /tmp/tarball.tgz ~поки тарбол ще завантажується. Тоді вам нічого не потрібно робити.

Коли завантаження закінчиться і навіть після того, як ваша програма видалила "оригінал", точна копія все ще повинна знаходитися у вашому домашньому каталозі.

Я використовую "жорсткі посилання", щоб створити резервну копію деяких моїх "HowTos" та фрагментів

У мого користувача / root є каталог з назвою "Спільні документи". У цьому каталозі у мене є "жорсткі посилання" на мої поради, підказки, фрагменти, методи роботи, які містяться у відповідних каталогах; php, mysql, css, regex, формули, linux та ін. Якщо їх мати на одному місці, це набагато простіше використовувати, оновлювати їх, ніж потрібно стрибати в своїх документах / каталогах, які шукають ці документи, які я часто використовую.

Давно я використовував символьні посилання. Я б сумлінно створив резервну копію цього загального каталогу "Спільні документи" на своєму сервері. Проблема полягає в тому, що символьні посилання або "м'які посилання", якщо їх скопіювати (cp -auv) або дозволити та скопіювати, ТОЛЬКО резервуйте або скопіюйте "посилання", а НЕ вміст документа. Отже, мені доведеться перейти до каталогів і скопіювати кожен з двох десятків файлів з фактичного місця їх розташування.

За допомогою HARD LINKS я можу скопіювати, tar, rsync каталог "Shared Docs" і фактично створити резервну копію цих широко розповсюджених документів з упевненістю. Мені це справді смоктало, коли я зрозумів, що я створюю резервну копію 0 файлів посилань, а не інформацію.

Недоліком використання "Жорстких посилань" є те, що введення ls в каталозі не дає вам свідчення про те, що файл "пов'язаний" з іншим файлом або там, де цей файл може існувати спільно. Існують способи їх пошуку, але я кажу, що це не очевидно, за допомогою простого ls -l -> вказує на ... Отже, я зазвичай додаю примітку до початку документа із зазначенням того, який каталог / файли 'цей ​​файл 'поділено з'

Landis.