Коли ви використовуєте одне над іншим?

Різна семантика між жорсткими і м'якими посиланнями робить їх придатними для різних речей.

Посилання:

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

Символічні посилання (м'які посилання)

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

Суть обох типів посилань полягає в тому, щоб забезпечити спосіб відображення файлу в двох місцях одночасно. Це має багато застосувань. 9 разів з 10 ви хочете використовувати символічні посилання.

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

На відміну від Windows, вони працюють на рівні файлової системи, а не на оболонці або на рівні додатків, тому майже будь-яка програма буде «слідувати» посиланнями, як очікувалося. ls -alможе бути використаний як швидкий спосіб побачити, куди "вказують" символьні посилання.

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

Я не можу придумати ситуацію, коли використання жорстких посилань є звичайним або навіть необхідним, якщо ви навмисно не хочете запобігти видаленню файлів або виконайте якусь дивну роботу низького рівня з розділами або іншими речами, пов’язаними з файловою системою. EDIT: Хоча в інших відповідях на це питання чудові ідеї!

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

Жорсткі посилання - це лише посилання на ті самі простори на диску, тому "чому" ви не можете жорстко посилатись на інші файлові системи.

Символьні посилання - це файли, що посилаються на інші файли (як ярлики Windows), можливо, в тій же файловій системі, а може і ні.

EDIT: Я поясню щось більше. Кожен існуючий файл має як мінімум 1 жорстке посилання. Жорсткі посилання - це спосіб отримати доступ до вмісту inode файлової системи. Ви можете отримати номер inode файлу за допомогою ls -iта отримати кількість твердих посилань, statяк показано в цьому прикладі:

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

Дякую @geekosaur за це посилання:

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

і це (відредаговано):

Жорсткі посилання дуже корисні для механізмів додаткового резервного копіювання на основі диска, таких як Apple Time Time , тому що ви можете мати повне дерево каталогів для кожної резервної копії, діючи простір для файлів, які не змінилися - і файлова система веде облік підрахунку довідок, так коли остання посилання на дану версію відходить, оскільки термін дії резервної копії минув / видалився з просторових міркувань, простір, який він використав, автоматично відновлюється. Деякі поштові клієнти також використовують його для повідомлень, поданих у кілька папок, з тієї ж причини.

Ура

М'яке посилання вказує на інше ім'я шляху. Таке ім'я може насправді існувати або не може існувати. Шлях не шукається, поки ви не отримаєте доступ до симпосилання. Якщо шлях не існує, коли ви намагаєтесь отримати доступ до нього, у вас порушена символьна посилання.

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

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

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

"жорсткі" посилання мають однаковий inode

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

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

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

Якби я створив те саме, але з "м'яким" або символічним посиланням, тоді є один файл, один inode та новий файл із власним inode, що вказує на перший.

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

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

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

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

Жорсткі посилання - це додаткові записи каталогів для одного файлу. Це означає

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

• Багато редакторів не записують новий вміст у той самий файл під час збереження, а скоріше виконують таку процедуру:

  1. Запишіть новий вміст у новий файл.
  2. Перейменуйте старий файл на ім’я резервної копії (або, якщо не зберігаєте резервні копії попередньої версії файлу, просто видаліть його).
  3. Перейменуйте щойно записаний файл на ім'я попереднього файлу.

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

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

З іншого боку, символічні посилання зберігають ім'я шляху (ім'я до файла, а точніше його запис у каталозі - потенційно включає його шлях, як-от /bin/shабо subdir/foo.bar) - іншого файлу. Якщо ім'я шляху відносне, воно завжди інтерпретується відносно каталогу, в якому міститься посилання. Це означає:

• Символічне посилання може посилатися на файли в іншій файловій системі (навіть до файлової системи, яка сама по собі не підтримує жорсткі або м'які посилання, як FAT).

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

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

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

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

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

HARD LINK (тільки файли) проти SOFT LINK (файли або каталоги) проти BIND (HARD LINK для каталогів)

_{(джерело: freesoftwareservers.com )}

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

Подумайте про це, якщо ви "видалили" все з свого накопичувача, ви могли б запустити програмне забезпечення для відновлення даних, оскільки "1" і "0" все ще є, ви просто видалили всі жорсткі посилання. Метою програмного забезпечення для відновлення є відновлення жорстких посилань, щоб мати сенс 0 і 1

Я прочитав чудовий "один лайнер", який мав все це має сенс, і я хотів поділитися!

Усі файли в Linux - це "жорсткі посилання" на 0 і 1 на диску. Коли ви створюєте дані (0 і 1), ОС створює жорстке посилання в дереві файлів для посилання на це місце на жорсткому диску.

Створіть HARD LINK 2 та видаліть HARD LINK 1 Оригінальний файл :

Ви можете створити інше жорстке посилання та видалити вихідний файл, і ви все одно матимете доступ до новоствореного жорсткого посилання.

Видаліть ФАЙЛ (HARD LINK 1), який МУЖЕ ПОСИЛАНО на:

Якщо ви видалили HARD LINK 1, чи вважаєте ви, що SOFT LINK спрацює? Ні, ОС повідомить, що HARD LINK 1 не існує.

Видаліть SOFT LINK на HARD LINK:

У зворотному випадку, якщо ви видалите SOFT LINK, чи спрацює HARD LINK? Так. Поки в ОС є один файл HARD LINK, він повідомляє, що заливка не була видалена.

- Також варто вивчити / відзначити BIND - спосіб BIND двох каталогів, як, наприклад, посилання на два каталоги, але він прозорий для ОС (ОС може сказати, коли ви Symlink, а деякі мають правила щодо погоди, вони можуть слідувати посиланнями). Він використовує Mount, а не LS і може бути налаштований через FSTAB.

Що таке кріплення BIND

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

Це дуже старе питання, але у мене є випадок використання, який вимагає від мене жорстких посилань.

Я музикант, і тому на моєму Mac є багато, багато і багато аудіофайлів різного роду на декількох жорстких дисках. Терабайти варто. У мене вони здебільшого організовані дуже добре з каталогами symlink, так що я можу їх знайти за видавцем вмісту, стилем / звуком та іншими критеріями, залежно від того, як я думаю в той час. На жаль, одна програма, яку я використовую, Ableton Live, абсолютно не здатна переглядати псевдоніми або посилання зі свого файлового браузера. Єдине рішення, яке я знайшов, - це створити жорсткі посилання каталогів, в які я хочу, щоб вони могли бачити, і тоді все працює чудово.

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