Використовувати випадки для жорстких посилань? [зачинено]

У яких ситуаціях хотілося б використовувати жорстке посилання, а не м'яке посилання? Я особисто ніколи не стикався з ситуацією, коли я хотів би використовувати жорстке посилання на софт-посилання, і єдиний випадок використання, який я натрапив під час пошуку в Інтернеті, - це дедуплікація однакових файлів .

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

Медіа-колекція, де всі файли зберігаються в одному, плоскому, каталозі та сортуються в інші каталоги залежно від різних критеріїв, наприклад: рік, тема, виконавець, жанр тощо. Це може бути колекція особистого фільму чи колектив комерційної студії працює. Фактично закінчений, файл зберігається, імовірно, не буде модифікований та сортований, можливо, у декілька місць за посиланнями.

Майте на увазі, що поняття "оригінал" та "копія" не застосовуються до жорстких посилань: кожне посилання на файл є оригіналом, у нормальному розумінні немає "копії". Однак для опису випадку використання терміни імітують логіку поведінки.

"Оригінал" зберігається в каталозі "каталог", а відсортовані "копії" жорстко пов'язані з цими файлами. Атрибути файлів у каталогах сортування можуть бути встановлені на r / o, запобігаючи випадковим змінам імен файлів та сортованої структури, тоді як атрибути в каталозі каталогів можуть бути r / w, дозволяючи змінювати його за потребою. (У цьому випадку можуть бути музичні файли, де деякі гравці намагаються перейменовувати та реорганізовувати файли на основі тегів, вбудованих у медіа-файл, із введення користувача або пошуку в Інтернеті.) Додатково, оскільки атрибути каталогів "копіювати" можуть бути іншими "оригінальний" каталог, сортована структура може бути доступною для групи або світу з обмеженим доступом, тоді як основний "каталог" доступний лише для головного користувача, з повним доступом. Однак самі файли завжди матимуть однакові атрибути у всіх посиланнях на цей inode. (АСЛ можна було б дослідити, щоб покращити це, але не моя область знань.)

Якщо оригінал перейменований або переміщений (наприклад, один каталог «каталогу» стає занадто великим для управління, наприклад) жорсткі посилання залишаються дійсними, м'які посилання порушуються. Якщо "копії" переміщені, а софт-посилання відносні, то програмні посилання знову будуть розірвані, а жорстких посилань не буде.

Примітка. Здається, існує невідповідність того, як різні інструменти повідомляють про використання диска при включенні програмних посилань. Однак із жорсткими посиланнями це здається послідовним. Таким чином, зі 100 файлів у каталозі, відсортованих до колекції "тегів", легко може бути 500 "примірників". (Для колекції фотографій, скажімо, дата, фотограф і в середньому 3 "тематичні" теги.) Дельфін, наприклад, повідомив би про те, що 100 файлів для жорстких посилань та 600 файлів, якщо використовуються м'які посилання. Цікаво, що він повідомляє про те саме використання дискового простору в будь-якому випадку, тому схоже на велику колекцію невеликих файлів для програмних посилань і невелику колекцію великих файлів для жорстких посилань.

Застереження до цього типу використання є те, що у файлових системах, які використовують COW, зміна "оригіналу" може порушити жорсткі посилання, але не порушити програмні посилання. Але якщо намір мати головну копію, після редагування, збереження та сортування, COW не входить у сценарій.

Жорсткі посилання корисні для випадків, коли ви не хочете пов'язувати існування обох файлів. Врахуйте це:

touch a
ln -s a b
rm a

Зараз bмарно. (І ці кроки можуть траплятися досить далеко один від одного, робити їх різними людьми тощо)

Беручи до уваги міцне посилання,

touch a
ln a b
rm a

b все ще присутній і правильний.

Одна програма може змінити свою поведінку залежно від того, яке ім’я запускається як:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Що в джерелі вирішено через щось подібне

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

хоча точні відомості будуть різними залежно від ОС та мови, що стосується.

Це дозволяє (здебільшого) однаковий код не потрібно збирати до двох (переважно) однакових бінарних файлів. Майте на увазі, що Unix датується днями, коли дисковий простір був надто дорогим, хоча, згідно зі словами Стівенса в розділі APUE 4, посилання на BSD4.2 (1983) були заміщені різними обмеженнями жорстких посилань. Тестова програма, щоб перевірити, чи використовується ім'я symlink як ім'я програми, виглядає приблизно так:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

І тестується через:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Коли моє програмне забезпечення P2P закінчує завантаження певного файлу, файл розміщується у певному каталозі. Завантажені файли навряд чи потребують редагування. Поширений випадок - я роблю жорстке посилання в інший каталог, де мені потрібен файл.

Переваги:

• Я все ще поділяюся файлом у мережі P2P, як слід, навіть якщо я rmабо mv"копіюю".
• Файл також знаходиться в тому напрямку, де мені це потрібно; більшість таких місць не є спільними.
• Я можу rm"оригінал" припинити ділитися файлом; ця операція не впливає на "копію" в потрібному місці.
• Мій диск використовується лише один раз.

Основний момент: якби я заздалегідь знав, який файл я буду rmпершим, я міг би перейти до symlink. Але я ніколи не знаю.

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

Як згадувалося, немає жодної концепції оригіналу та копій при роботі з жорсткими посиланнями, усі записи каталогів (жорсткі посилання) - це просто посилання на існування файлу (вказують на його inode) без пріоритету, отже, також немає зламаних твердих посилань. .

Таким чином , тут є деякі випадки використання , які жорсткі посилання присутнім , але softlinks не роблять :

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

2. Ще одна причина - уникнути витрачання місця на зберігання, яке потрібно для отримання декількох копій одного файлу, і все ж дозволить chrootсистематичному виклику скористатися підмножиною файлів у корені файлової системи "master" (символічні посилання ніколи не можуть посилатися на файли ззовні chrootпісочниця, навіть якщо вони мають відносні шляхи).

3. Ще одна дуже важлива, але рідко згадувана причина існування жорстких посилань - це ..підкаталоги. Ці ..каталоги на насправді (в більшості Unix ФС реалізації) жорсткі посилання на батьківський каталог, без жорстких посилань це повинно бути реалізовано в абсолютно по- іншому, в той час як наявність жорстких посилань робить це дуже легко реалізувати.

Дуже поширений приклад у реальному світі, який потребує жорстких посилань:

git clone --reference <repository>

Цей клон із місцевого репоту Git із майже нульовим копіюванням. Замість того, щоб копіювати об’єктні файли (незмінні файли, які використовує Git для своєї "бази даних"), він просто жорстко посилається на них.

Будь-яке репо може видалити об'єкт, але індекс залишається дійсним для решти репостів. І якщо об’єкт видалено з усіх репостів, він видаляється з диска. Жорсткі посилання дозволяють отримати дуже надійне і швидке рішення. Дуже часто зустрічається на серверах CI.

Існує версія , не твердо посилання: git clone --shared <repository>. Це, однак, непогано і має ще багато застережень, оскільки всі працюють над одним і тим же каталогом.

Нещодавно у мене був випадок використання дещо безпечної процедури оновлення систем, що базуються на U-Boot, де uImageє м'яке посилання, що вказує на зображення для завантаження, ідея полягала в тому, що відключення електроенергії не повинно створювати проблем, незалежно від того, в який момент часу процес це відбувається (якщо припустимо, що файлова система працює):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Без жорстких посилань це було б не так просто.

/ редагувати:

Завдяки коментарям я тепер знаю, що було б краще зробити:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

(Тут rmє для того, щоб можна було краще уникнути дивного стану, наприклад, якщо uImageщось несподіване може призвести до mvневдачі [але не обов'язково попереднього ln -sfрішення].)

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

BackupPC - це система резервного копіювання, яка використовує жорсткі посилання на сервери для забезпечення дедуплікації на рівні файлів.

Спочатку файли зберігаються у дереві каталогів «пул» на основі хеша md5. Будь-яка резервна копія, яка використовує цей файл, забезпечує міцне посилання на файл пулу. По мірі закінчення / видалення резервних копій їх жорсткі посилання видаляються з файлової системи.

Тут жорсткі посилання перевершують м'які посилання, оскільки вони забезпечують автоматичний підрахунок посилань. Завдання Cron періодично видаляє будь-які файли в каталозі пулу, які не мають більше ніж одне посилання.

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

Інший випадок використання: сервер веб-додатків tomcat Java розглядає імена файлів як метадані. Ява "війни" файл повинен бути названий на основі його шляху на веб-сервері.

наприклад: foo.war код Java, який обслуговує URL-адресу/foo

На жаль, він вирішує посилання, перш ніж приймати це рішення.

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

foo.warсимвольне посилання foo-20170129.warне працює

foo.warжорстке посилання на foo-20170129.warтвори.

мені не подобається така поведінка tomcat, але жорсткі посилання дають мені шлях до цього.