Як сказати, який файл оригінальний, якщо створено жорстке посилання


34

Наприклад, у мене є файл myold_file. Потім я використовую lnдля створення жорсткого посилання як mylink:

ln myold_file mylink

Тоді, навіть використовуючи ls -a, я не можу сказати, що є старим.

Чи все-таки можна сказати?


2
Протиріччя: Якщо ви робите ls > a; ln a b; rm a; ln b c, який з них "оригінальніший", ніж інший? aпішло, тобі залишилось bі c...
glglgl

2
Чого ви намагаєтесь досягти? Чого ви намагаєтесь досягти? Не існує «оригіналу» як такого. Файл - це inode, що містить метадані та колекцію блоків, що містять дані. Каталог може містити посилання на файл, а це посилання - це ім'я та номер вводу. Ви можете створити будь-яку кількість посилань на файл. Файли ніколи не можуть мати менше одного посилання.
Йохан

Для детального пояснення прийнятої відповіді на це питання: Дивіться прийняту відповідь на це питання .
Утку

Відповіді:


93

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


4
Це однозначно правильна відповідь: питання ОП засноване на непорозумінні.
Даніель Ервікер

8
@Adnan Власне, ні: два жорстких посилання - це один і той же файл. Вони різні записи каталогів. Термінологія Дженні Д правильна.
Жиль "ТАК - перестань бути злим"

1
@Gilles Я не бачу, як це може бути правильним. Два жорстких посилання - це не два файли ; жорсткі посилання - це не файли. Вони вказують , отже, посилання на той самий файл (який є фізичним розташуванням на диску). Сказати, що "дві жорсткі посилання - це буквально один і той самий файл" - неправильно.
Аді

1
@JennyD І це майже єдиний спосіб, коли я почув, як "жорстке посилання" використовується; покажчик файлової системи на inode. Ну, мабуть, ми всі помиляємось і правильно. Я перестану аргументувати це, оскільки це безглуздо. Ви відповідаєте мені здається правильним, у вас є +1 від мене, і я залишу це на цьому.
Аді

5
Скажімо, що жорстке посилання "є" файл порівнює речі різних категорій, що технічно неправильно. Але зважаючи на те, що ми, як правило, кажемо, " .bashrcце файл, що містить ...", коли ми маємо на увазі, "відносний шлях .bashrcвідноситься до файлу, що містить ...", це звичайне співвідношення категорій, і ми повинні розуміти, що коли б посилався на шлях або запис каталогу "будучи" файлом, ми маємо на увазі файл, на який він посилається. З огляду на це розуміння, два важких посилання можуть "бути" одним файлом. Відкидаючи цю конвенцію на користь формальної мови, вони не можуть. Обидві позиції мають своє місце :-)
Стів Джессоп

16

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

Створення жорсткого посилання - це операція запису в каталог, який містить посилання. Таким чином, він оновлює каталоги mtime. Так що якщо

  1. посилання є в різних каталогах

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

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

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

ls -lU

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


2
Ніякої згадки про selinux, аудиторські траси чи шпигунство за журналом файлової системи ??? усмішка Без аудиторського сліду, немає ніякого способу дізнатися - все інше - обчислена здогадка
Рікі Бім,

1
@mikeserv Якщо ви хочете навчити інших таким чином, то вам слід хоча б навчитися правильно цитувати. У запитанні не вказано "який файл". І навіть якби це було тоді, це було б просто формулюванням проблеми, і кидання мозку на розуміння питання легко виявить, що це насправді.
Хоуке Лагінг

4
Трюк каталогу mtime спрацює, якщо обставини вірні (що рідко). Однак, як ви це презентуєте, іноді ви прийдете до протилежного висновку. Каталог mtime є лише вагомим показником, якщо він дорівнює ctime файлу. Але ls -lUхитрість не працюватиме в сучасних файлових системах (ext4, btrfs, zfs), там записи взагалі не відображаються в порядку створення.
Жил "ТАК - перестань бути злим"

2
@mikeserv - питання ОП засноване на непорозумінні. Якби вони rm myold_fileтоді, mylinkвони все одно існували б і працювали ідеально, оскільки це однаково хороший запис, що стосується тієї ж основної індеди. Тільки після видалення обох систем система може відкинути вклад. Після того, як жорстке посилання було використано для створення двох записів файлової системи, що посилаються на один і той же файл, вони є рівнозначними. (Зауважте, що тут "файл" означає "інода, що містить дані для файлу, на відміну від каталогу". Див.: En.wikipedia.org/wiki/Inode
Даніель Ервікер

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

10

Якщо ви покладаєтесь на час останньої модифікації каталогів, і не знаєте, як і коли ці каталоги змінюються, покладаючись на mtime, це призведе до того, що ви помилитесь деякий відсоток часу. Проблема тут полягає в тому, що файл представлений у файловій системі введенням, а не записом каталогу. Запис в каталозі (ім'я файлу) вказує на inode, а не на файл.

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


8

Я думаю, що це питання (цілком обґрунтовано) хибне, що таке міцне посилання насправді. Я думаю, однак, найправильніша пряма відповідь - «Вони обоє є» .

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

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


Знаєте, Боб / Джо може бути дуже чутливим до свого віку ... Порівняння жорсткого / м'якого посилань є хорошим - особливо якщо врахувати, що жорстке посилання просто отримає запис, доданий у файл каталогу - вже існуючий inode - але soft-link є самим файлом, і таким чином присвоюється його власний inode. Тим не менш, в обох випадках час модифікації є актуальним лише для пов'язаного файлу, оскільки єдиними модифікаціями, які можуть бути внесені до посилання будь-якого значення, буде просто створення / видалення.
mikeserv

2

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

Подумайте про каталог як таблицю, в якій перераховані імена файлів та номери inode.

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

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

Доступ до даних файлу через ім'я файлу - це три кроковий процес: ім'я файлу шукається в каталозі, щоб отримати номер inode. Потім посилається на inode, щоб знайти відповідний диск (або блоки), що містить дані. Потім нарешті ці блоки читаються / записуються.

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

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