Чим відрізняється символічне посилання від жорсткого посилання?


768

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


2
про "не розумію використання жорсткого посилання", його можна використовувати в системах побудови, які роблять багато копіювання бінарних файлів. Створення жорсткого посилання замість фактичної копії прискорює роботу. MSBuild 4.0 підтримує це.
Анкуш

13
Я вважаю це посилання дуже корисним для його розуміння. askubuntu.com/questions/108771/…
kta

2
unix.stackexchange має хороший перелік точок кулі ... дуже корисно, оскільки він викладає всі обмеження дуже стисло і його легко пропустити. (багато цих пунктів охоплюють крайові випадки / застереження, які згадуються лише в коментарях до цього питання ... або взагалі не згадуються)
Тревор Бойд Сміт

Відповіді:


779

Під файловою системою файли представлені вводами. (Або це численні вставки? Не впевнені.)

Файл у файловій системі в основному є посиланням на inode.
Тоді жорстке посилання просто створює інший файл із посиланням на той самий базовий inode.

Коли ви видаляєте файл, він видаляє одне посилання на базовий inode. Inode видаляється (або видаляється / перезаписується) лише тоді, коли всі посилання на індет були видалені.

Символічне посилання - це посилання на інше ім’я файлової системи.

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

Примітка: жорсткі посилання дійсні лише в одній файловій системі. Символічні посилання можуть охоплювати файлові системи, оскільки вони просто ім'я іншого файлу.


2
Я впевнений, що i-вузли залежать від конкретного варіанту ОС; однак я вважаю, що це, як правило, окремий i-вузол. I-вузол містить інформацію про файл та інформацію про те, де дані зберігаються на диску. Великі файли матимуть непрямі покажчики на додаткові таблиці.
Терсон

76
Ви можете додати корисну функцію того, що символічні посилання можуть перетинати файлові системи, а жорсткі посилання не можуть (вони повинні посилатися на файл у тій же файловій системі).
paxdiablo

52
Є гарне наочне пояснення у статті про Linux Gazette
Родріг

1
Я також написав блог про це після деяких читань та експериментів csharpbsharp.tumblr.com
Аднан Бхатті

1
@zen: Ви можете відключити / повторно встановити файлову систему будь-коли, коли вона не використовується. Для кореневого розділу це трохи хитро, але це можна зробити (не рекомендується). Щоб зробити це для кореня, як правило, найкраще завантажувати рядовий компакт-диск спочатку змінити кріплення та перезавантажити. Але вам слід задати подібне запитання супер користувачеві.
Мартін Йорк

464

Приємна інтуїція, яка може допомогти, використовуючи будь-яку консоль Linux (ish).

Створіть два файли:

$ touch foo; touch bar

Введіть до них деякі дані:

$ echo "Cat" > foo
$ echo "Dog" > bar

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

І як очікувалося:

$cat foo; cat bar
Cat
Dog

Давайте створимо жорсткі та м'які посилання:

$ ln foo foo-hard
$ ln -s bar bar-soft

Подивимося, що щойно сталося:

$ ls -l

foo
foo-hard
bar
bar-soft -> bar

Зміна імені foo не має значення:

$ mv foo foo-new
$ cat foo-hard
Cat

foo-hard вказує на inode, вміст файлу - що не було змінено.

$ mv bar bar-new
$ ls bar-soft
bar-soft
$ cat bar-soft  
cat: bar-soft: No such file or directory

Вміст файлу не вдалося знайти, оскільки м'яке посилання вказує на ім’я, яке було змінено, а не на вміст.

Так само, якщо fooвидалено, він foo-hardвсе ще містить вміст; якщо barвидалено, bar-softце лише посилання на неіснуючий файл.


12
чи означає це, що "файл" і "жорстке посилання" є однаковими, обидва вказують на inode? при видаленні файлу або жорсткого посилання вміст все ще існує до тих пір, поки один все ще вказує на правильне введення?
Даніель В.

1
@DanFromGermany Правильно. Вміст доступний до тих пір, поки щонайменше одне жорстке посилання (тобто файл) вказує на нього.
Адам Матан

6
touch blah1; touch blah2можна скоротити доtouch blah1 blah2
Дмитро Зайцев

11
@DmitriZaitsev Щоправда, але він буде менш читабельним для початківців IMO.
Адам Матан

8
Я думаю, що це найкраще зрозуміла відповідь стосовно багатьох відповідей, які я прочитав. Зразок краще, ніж купу тексту пояснень.
Скотт Чу

435

Як говориться, картина коштує тисячі слів. Ось як я візуалізую це:

введіть тут опис зображення

Ось як ми дійшли до цієї картини:

  1. Створіть ім’я myfile.txtу файловій системі, яке вказує на новий inode (який містить метадані для файлу та вказує на блоки даних, що містять його вміст, тобто текст "Привіт, світ!":

    $ echo 'Hello, World!' > myfile.txt
    
  2. Створіть жорстке посилання my-hard-linkна файл myfile.txt, що означає "створити файл, який повинен вказувати на той самий inode, який myfile.txtвказує на":

    $ ln myfile.txt my-hard-link
    
  3. Створіть м'яке посилання my-soft-linkна файл myfile.txt, що означає "створити файл, який повинен вказувати на файл myfile.txt":

    $ ln -s myfile.txt my-soft-link
    

Подивіться, що буде зараз, якщо myfile.txtбуде видалено (або переміщено): my-hard-linkусе ще вказує на той самий вміст, і, таким чином, це не впливає, тоді як my-soft-linkзараз вказує ні на що. В інших відповідях обговорюються плюси та мінуси кожного.


3
@ThunderWiring Під "точкою" я маю на увазі будь-яке посилання на посилання. У випадку жорсткого посилання воно посилається на індед безпосередньо (тобто той самий інод, на який посилається myfile.txt). Для м'якого посилання це посилання - це не inode (який містить дані), а, скоріше, це посилання на шлях файлової системи до myfile.txt(наприклад /home/Documents/myfile.txt)
akivajgordon

4
Мені дуже подобається ваша візуальна реакція @akivajgordon - дуже допомогла мені краще зрозуміти відмінності!
wmock

7
Десять тисяч слів!
SaganRitual

13
Можливо, я повільний, але ваша фотографія лише за два секунди розкрила 20 років таємниці.
jdk1.0

3
Найкорисніша відповідь, я божевільний, що це поховано так глибоко в цій посаді. Я дав би вам сто балів в Інтернеті, але, на жаль, я можу дати вам лише один.
Dagrooms

71

Жорсткі посилання корисні, коли вихідний файл переміщується. Наприклад, переміщення файлу з / bin в / usr / bin або в / usr / local / bin. Будь-яке символьне посилання на файл у / bin би цим було порушено, але жорстке посилання, будучи посиланням безпосередньо на вклад для цього файлу, не було б байдужим.

Жорсткі посилання можуть зайняти менше місця на диску, оскільки вони займають лише запис у каталозі, тоді як для посилання на ім'я, на яке вказує, потрібне власне введення.

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

Я також думаю, що такі речі, як mmap (2) і навіть відкриті (2), використовують таку ж функціональність, як і жорсткі посилання, щоб активувати inode файлу активним, так що навіть якщо файл від’єднається (2) ed, вклад залишається дозволити продовжувати доступ до процесу, і лише після завершення процесу файл дійсно відходить. Це дозволяє набагато безпечніші тимчасові файли (якщо ви можете змусити відкриті та від’єднані атомарні дії, які можуть бути POSIX API, яких я не пам’ятаю, тоді ви дійсно маєте безпечний тимчасовий файл), де ви можете читати / писати ваші дані, не маючи доступу до них. Що ж, це було правдою раніше / proc, що дало всім можливість переглядати дескриптори файлів, але це вже інша історія.

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


35

М'яке посилання :

м'який або символічний - це швидше скорочення до оригінального файлу .... якщо ви видалите оригінал, ярлик не виходить і якщо ви видалите лише це, з оригіналом нічого не відбувається.

Синтаксис м'якого посилання :ln -s Pathof_Target_file link

Вихід: link -> ./Target_file

Доказ: readlink link Також у ls -l linkвисновку ви побачите першу букву у lrwxrwxrwxвигляді l, що вказує на те, що файл є м'яким посиланням.

Видалення посилання: unlink link

Примітка. Якщо ви хочете, ваше програмне посилання може працювати навіть після переміщення його кудись із поточного режиму. Переконайтесь, що ви створюєте абсолютний шлях, а не відносний шлях, створюючи м'яке посилання. тобто (починаючи з / root / user / Target_file, а не ./Target_file)

Посилання:

Жорстке посилання - це більше дзеркальна копія або кілька шляхів до одного файлу. Зробіть щось у file1, і це з’явиться у файлі 2. Видалення одного все одно зберігає інше в порядку.

Inode (або файл) видаляється лише тоді, коли всі (жорсткі) посилання або всі шляхи до (того ж файлу) inode були видалені.

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

Синтаксис жорсткої посилання :ln Target_file link

Вихід: Файл із посиланням на ім’я буде створений з тим самим номером вводу, що і для Targetfile.

Доказ: ls -i link Target_file (перевірити їхні введення)

Видалення посилання: rm -f link (Видаліть посилання так само, як і звичайний файл)

Примітка . Символічні посилання можуть охоплювати файлові системи, оскільки вони просто ім'я іншого файлу. Тоді як жорсткі посилання дійсні лише в одній файловій системі.

У символічних посиланнях є деякі функції, жорсткі посилання відсутні:

  • Тверда посилання на вміст файлу. при цьому Soft link вказує на ім'я файлу.
  • тоді як розмір жорсткого посилання - це розмір вмісту, тоді як м'яке посилання має розмір імені файлу.
  • Жорсткі посилання мають один і той же індед. М’яких посилань немає.
  • Жорсткі посилання не можуть перетинати файлові системи. М'які посилання роблять.
  • Ви відразу знаєте, куди вказує символічне посилання, перебуваючи на жорстких посиланнях, вам потрібно вивчити всю файлову систему, щоб знайти файли, що мають однаковий inode.

    # find / -inum 517333

    /home/bobbin/sync.sh
    /root/synchro
    
  • жорсткі посилання не можуть вказувати на каталоги.

Жорсткі посилання мають два обмеження:

  • Каталоги не можуть бути важко пов'язані. Linux не дозволяє це підтримувати ациклічну структуру дерева каталогів.
  • Жорстке посилання неможливо створити у файлових системах. Обидва файли повинні бути в одній і тій же файловій системі, оскільки різні файлові системи мають різні незалежні таблиці вкладень (два файли в різних файлових системах, але з однаковим номером індексу будуть різними).

3
"у той час як розмір жорсткого посилання - це розмір вмісту, а м'яке посилання має розмір імені файлу." Просто для уточнення створення іншої жорсткої посилання впливає на вільний простір лише на кілька байтів.
Інго

34

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

Отже, якщо у нас є файл під назвою "a" і створимо жорстке посилання "b" і символічне посилання "c", яке всі посилаються на файл "a":

echo "111" > a
ln a b
ln -s a c

Виведення "a", "b" і "c" будуть:

cat a --> 111
cat b --> 111
cat c --> 111

Тепер видалимо файл "a" і подивимося, що відбувається з результатами "a", "b" і "c":

rm a
cat a --> No such file or directory
cat b --> 111
cat c --> No such file or directory

Так що трапилося?

Оскільки файл "c" вказує на файл "a", якщо файл "a" видалено, тоді файл "c" не буде нічого вказувати, він також видаляється.

Однак файл "b" вказує на місце зберігання або на вкладення файлу "a". Отже, якщо файл "a" буде видалений, він більше не вказуватиме на inode, але оскільки файл "b" робить, inode продовжуватиме зберігати будь-який вміст, що належав до "a", поки більше не з'являться більш жорсткі посилання на нього.


Може бути корисним зазначити, що файл є дуже абстрактним об'єктом і має всі абстрактні речі, реальні наміри реалізацій високого рівня можуть бути невідповідними належним поясненням, не ризикуючи здути абстракції.
Чолті Павло Ттіопік

28

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

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


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

21

Я зазначив би вас у Вікіпедії:

Кілька пунктів:

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

1
Теоретично (а в деяких випадках навіть на практиці) жорсткі посилання можуть вказувати і на каталоги (насправді "." Є жорстким посиланням на поточний каталог, а ".." - жорстке посилання на батьківський каталог). Але вони можуть бути небезпечними, тому більшість UNIX не дозволяють їм (або вимагають від вас спеціальних заходів, щоб зробити це). Apple використовує їх для впровадження машин часу, наприклад: earthlingsoft.net/ssp/blog/2008/03/x5_time_machine
Йоахім Зауер

3
Ви вказуєте на посилання на статтю ... це робить вас символічним посиланням?
Ян Кемпбелл

@JoachimSauer Ви вважаєте, що нова файлова система Apple усуне необхідність у Time Machine використовувати жорсткі посилання на каталоги?
cjm

Я знайшов пояснення wikipedia значно коротшим та конкретнішим, ніж пояснення у найкращих відповідях.
озера

9

Жорсткі посилання дуже корисні, коли ви робите резервні копії. Наприклад , дивіться rsnapshot . Ідея полягає в тому, щоб зробити копію, використовуючи жорсткі посилання:

  • скопіюйте номер резервного копіювання n в n + 1
  • скопіюйте резервну копію n - 1 в n
  • ...
  • скопіюйте резервну копію 0 в резервну копію 1
  • оновити резервну копію 0 будь-якими зміненими файлами.

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


6

Жорстке посилання проти м'якого посилання

Жорстке посилання Vs Soft link можна легко пояснити цим зображенням.


5
Я думаю, ваш м'який посилання pic неправильно. Точка: inode м'якого посилання не повинен вказувати на inode вихідного файлу. Тому що якщо ви перейменовуєте оригінальний файл, пов’язане програмне посилання мертве
percy507

@ percy507 так, ти маєш рацію - але я все одно вважаю це дуже приємним та інтуїтивним поясненням. Уявіть собі, що стрілки між індексами немає ...
Майкл Литвин

5

Додаю питання Ніка: коли корисні чи потрібні жорсткі посилання ? Єдиний додаток, який мені спадає на думку, в якому символічні посилання не виконали б роботу, - це надання копії системного файлу в хроноване середовищі.


Розподілена система w / точки монтажу в різних місцях на різних системах. Звичайно, це можна розробити поза системою, будучи послідовним.
Терсон

Я думаю, що @Tanktalus був чудовим прикладом.
Нік Stinemates

4

Від MSDN ,

Символічне посилання

Символічне посилання - це об'єкт файлової системи, який вказує на інший об’єкт файлової системи. Об'єкт, на який вказують, називається ціллю.

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

Символічні посилання призначені для сприяння міграції та сумісності програм з операційними системами UNIX. Microsoft впровадила свої символічні посилання для функціонування так само, як UNIX посилання.

Символічні посилання можуть бути абсолютними або відносними. Абсолютні посилання - це посилання, які задають кожну частину назви шляху; відносні посилання визначаються відносно того, де специфікатори відносних зв’язків знаходяться у визначеному шляху

Приклад абсолютного символічного зв’язку

X: "C:\alpha\beta\absLink\gamma\file"
Link: "absLink" maps to "\\machineB\share"
Modified Path: "\\machineB\share\gamma\file"

Приклад відносних символьних посилань

X: C:\alpha\beta\link\gamma\file
Link: "link" maps to "..\..\theta"
Modified Path: "C:\alpha\beta\..\..\theta\gamma\file"
Final Path: "C:\theta\gamma\file"

Тверде посилання

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

Щоб створити жорстке посилання у Windows, перейдіть до місця створення посилання та введіть цю команду:

mklink /H Link_name target_path

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

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

З'єднання

NTFS підтримує інший тип зв'язку, який називається з'єднанням. MSDN визначає це так:

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

Жирні частини, розташовані в розділі твердого з’єднання та секції з'єднання, показують основну різницю між ними.

Команда, щоб створити перехід у Windows, перейдіть до місця створення посилання, а потім введіть:

mklink /J link_name target_path

3

Також:

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

3

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

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


3

Те, що ви вважаєте звичайним «файлом», - це насправді дві окремі речі: дані про файл та запис у каталозі. Коли ви створюєте жорстке посилання на файл, ви фактично створюєте другу запис каталогу, що стосується тих же даних. Обидві записи каталогу мають однаковий функціонал; кожен з них може бути використаний для відкриття файлу для його читання. Таким чином, у вас насправді немає "файла плюс жорстке посилання", у вас є "дані файлу з двома записами в каталог". Те, що ви вважаєте видаленням файлу, фактично видаляє запис каталогу, а коли останній запис каталогу для даних видаляється, також видаляються і самі дані. Для звичайних файлів, у яких є лише одна запис каталогу, видалення запису каталогу буде видалено дані, як завжди. (Поки файл відкривається, ОС створює тимчасове посилання на файл,

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

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


2

Запис у каталозі посилається на структуру:

struct dentry{
    ino_t ino;
    char  name[256];
}

ino - кількість inode, ім'я - ім'я файлу, структура inode, можливо, як:

struct inode{
      link_t nlink; 
      ...
}

наприклад, ви створюєте файл / 1, запис у каталозі може бути таким:

struct dentry{
     ino_t ino; /* such as 15 */
     char  name[256]; /* "1" */
} 

структура inode може, як:

   struct inode{ /* inode number 15 */
         link_t nlink; /* nlink = 1 */
         ...
    }

тоді ви створюєте жорстке посилання (може бути / 100), запис у каталозі може бути таким:

  struct dentry{
     ino_t ino; /* 15 */
     char  name[256]; /* 100 */
  }

структура inode може, як:

   struct inode{ /* inode numebr 15 */
         link_t nlink; /* nlink = 2 */
         ...
    }

тоді ви створюєте символічне посилання (може бути / 200) на файл 1, запис каталогу може бути таким:

  struct dentry{
        ino_t ino; /* such as 16 */
        char  name[256]; /* "200" */
  }

структура inode може, як:

   struct inode{ /* inode number 15 */ 
         link_t nlink; /* nlink = 2 */
         ...
    }

   struct inode{ /* inode number 16 */
         link_t nlink; /* nlink = 1 */
         ...
    } /* the data of inode 16 maybe /1 or 1 */

2

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

У мене є файл f6у моєму поточному каталозі, а також каталог з іменем t2.

Файл названий f1і ./t2/f2є символічними посиланнями на f6.

Файл з назвою f7і ./t2/f8є посиланнями f6.

Щоб знайти як м'які, так і жорсткі посилання, ми можемо використовувати:

$ find -L . -samefile f6 

> ./f1
> ./f6
> ./f7
> ./t2/f2
> ./t2/f8

Щоб знайти лише жорстке посилання, ми можемо використовувати:

$ find . -xdev -samefile f6

> ./f6
> ./f7
> ./t2/f8

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

Тож пошук по жорсткому посиланню відбувається дещо швидше, ніж пошук програмних посилань (Будь ласка, виправте, якщо я помиляюся чи не зрозуміла).


1

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


Ні. Симпосилання - це не "інша назва цього ж файлу", це власний файл, посилання на цільовий файл.
Кусалаланда

1

Мої два центи за користування:

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

ln -s /long/folder/name/on/long/path/file.txt /short/file.txt

Внесені зміни /short/file.txtбудуть застосовані до вихідного файлу.

Для переміщення великих файлів можна використовувати жорсткі посилання:

$ ls -lh /myapp/dev/
total 10G
-rw-r--r-- 2 root root 10G May 22 12:09 application.bin

ln /myapp/dev/application.bin /myapp/prd/application.bin

Миттєва копія в іншу папку та оригінальний файл (увімкнено /myapp/dev) можна переміщувати чи видаляти, не торкаючись цього файлу/myapp/prd


0

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

Одного разу я завантажив програмне забезпечення в папку Downloadsдля встановлення. Після того, як я це зробив sudo make install, деякі виконувані файли були cpвідредаговані в локальну папку біна. Тут cpстворюється жорстке посилання . Я був задоволений програмним забезпеченням, але незабаром зрозумів, що Downloadsце не гарне місце в довгостроковій перспективі. Тому я mvредагував папку програмного забезпечення в sourceкаталог. Ну, я все ще можу запускати програмне забезпечення, як і раніше, не турбуючись про будь-які цільові речі, наприклад, в Windows. Це означає, що жорстке посилання знаходить Inode безпосередньо та інші файли навколо.


0

У цій відповіді, коли я кажу файл, я маю на увазі місце в пам'яті

Усі збережені дані зберігаються в пам'яті за допомогою структури даних під назвою inode Кожен inode має inodenumber. Номер inode використовується для доступу до inode. Усі жорсткі посилання на файл можуть мати різні назви, але мають однаковий номер inode. Оскільки всі жорсткі посилання мають однаковий числовий номер (який входить до одного і того ж інода), усі вони вказують на одну і ту ж фізичну пам'ять.

Символічне посилання - це особливий вид файлу. Оскільки це також файл, він матиме ім'я файлу та номер inode. Як сказано вище, номер inode підкреслює вкладку, яка вказує на data.Now, що робить символічне посилання особливим, це те, що inodenumbers у символічних посиланнях отримують доступ до тих узорів, які вказують на "шлях" до іншого файлу.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.