Яка різниця між жорстким посиланням та файлом?

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

Яка різниця між файлом і жорстким посиланням? Жорстке посилання вказує на inode, що таке файл? Сам запис inode? Або індед із твердим посиланням?

Скажімо, я створюю файл із дотиком. Потім в таблиці inode створюється запис inode . І я створюю жорстке посилання, яке має те саме число inode, що і файл. Тож я створив новий файл? Або файл просто визначений як inode?

Дуже коротка відповідь:

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

Файли та каталоги Unix працюють точно так само, як файли та каталоги в реальному світі (а не як папки в реальному світі); Файлові системи Unix (концептуально) структуровані так:

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

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

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

Моє запитання полягає в тому, в чому різниця файлу і жорсткого посилання?

Різниця між файлом та жорстким посиланням така ж, як і різниця між вами та рядком із вашим іменем у телефонній книзі.

Жорстке посилання вказує на inode, що таке файл? Вводити сам запис? Або Inode із твердим посиланням?

Файл - це анонімний фрагмент даних. Це воно. Файл не є inode, файл має inode, як і ви не номер соціального страхування, у вас є SSN.

Жорстке посилання - це ім'я файлу. Файл може мати багато імен.

Скажімо, я створюю файл з дотиком, тоді в таблиці Inode створюється запис Inode .

Так.

І я створюю жорстке посилання, яке має однаковий номер Inode з файлом.

Ні. На жорсткому посиланні немає номера inode, оскільки це не файл. Тільки файли мають номери номерів.

Жорстке посилання асоціює ім'я з номером inode.

Тож я створив новий файл?

Так.

Або файл просто визначений як Inode?

Ні. У файлі є inode, це не inode.

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

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

Розгляньте файли як кімнати та записи каталогів як двері. "Відкрити файл /foo/bar" означає "піти в коридор /fooі піти в кімнату bar". "Іти до кімнати bar" насправді означає "відкрити двері, позначені barі ввійти до кімнати", але "піти в кімнату bar" - це непересічний спосіб сказати те ж саме коротше. Можливо мати кілька дверей, що ведуть до однієї кімнати.

Коли ви створюєте жорстке посилання на існуючий файл ( ln existing new), ви створюєте друге посилання на той самий файл, тобто ви створюєте нову запис каталогу, що посилається на вже існуючий файл. Після створення обидві записи каталогів мають рівноправний статус: не існує жодної, яка є "первинною", а одна - "вторинною", вони просто обидві посилання на один і той же файл.

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

На додаток до всіх інших відповідей хочу зазначити наступні важливі властивості:

Програмне посилання - це справжня посилання, тобто це невеликий файл, який містить ім'я шляху. Розв’язання програмного посилання відбувається прозоро до програми: якщо процес відкриває файл, скажіть, /this/path/hereщо є посиланням, яке вказує на /that/other/pathто, що вся обробка відкриття /that/other/pathвиконується ОС. Крім того, якщо /that/other/pathвипадково відбувається саме посилання, то цим також займається ОС. Насправді ОС слідує за ланцюжком посилань, поки не знайде щось інше (наприклад, звичайний файл) або до тих пір, поки не досягне SYMLOOP_MAX(див. sysconf(3)) Багатьох записів, і в цьому випадку ОС (точніше: відповідно до системного виклику) повертає помилку і встановлює errnoдо ELOOP. Таким чином, циркулярна посилання на кшталт xyz -> xyzне зупинить процес. (Для систем Linux див. path_resolution(7)Докладні відомості.)

Зауважте, що процес може перевірити, чи ім'я контуру є символьним посиланням чи ні, використовуючи lstat(2)та може змінювати свої атрибути файлів (зберігаються в таблиці inode) через lchown(2)та інші (див symlink(7). Всю історію).

Тепер, з точки зору дозволу, ви помітите, що символьні посилання завжди мають дозволи 777 ( rwxrwxrwxу символічному позначенні). Це пов’язано з тим, що будь-який інший дозвіл у будь-якому випадку можна обійти шляхом доступу до фактичного файлу. І навпаки, 777 для символьної посилання не робить доступним для цього символьного файлу, якщо він був недоступний в першу чергу. Наприклад, символьне посилання з дозволами 777, що вказує на файл з дозволами 640, робить файл не доступним для "інших" (для широкої громадськості). Іншими словами, файл xyzдоступний через символьне посилання, якщо і тільки якщо він є безпосередньо доступним, тобто без опосередкованості. Таким чином, дозволи на симпосилання не мають жодного ефекту захисту.

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

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

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

Проста відповідь:

• Запис файлу в каталозі є міцним посиланням на цей файл.

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

У перші дні Unix файли внутрішньо були введеннями на певному дисководі. Імена файлів були більш привітним способом доступу до них.

Жорстким посиланням було призначено кілька імен файлів для inode. Ви можете створити файл, жорстко зв’язавши з ним друге ім’я та видалити ім'я, і ​​це було не відрізнятись від того, що ви створили файл з другим іменем в першу чергу.

Дійсно, системний виклик, який програмі потрібно використовувати для видалення файлу, є "від’єднати (2)". Дані не зникають, поки прізвище не від’єднано від inode. (і inode не відкривається десь процесом)

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

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

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

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

Файл - це широко використовувана концепція записів у файловій системі.

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

Моє запитання полягає в тому, в чому різниця файлу і жорсткого посилання? Жорстке посилання вказує на inode, що таке файл? Вводити сам запис? Або Inode із твердим посиланням?

Скажімо, я створюю файл з дотиком, тоді в таблиці Inode створюється запис Inode. І я створюю жорстке посилання, яке має однаковий номер Inode з файлом. Тож я створив новий файл? Або файл просто визначений як Inode?

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

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

Якщо ви програміст на C ++ або Java, ви можете прочитати про std :: fileystem :: file_type , java.io.File та java.nio.file.Files .

Деталі про відмінності між жорстким та м'яким посиланням можна знайти у посиланні у коментарі infixed.

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

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

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