Как программно проверить, поддерживает ли терминал курсив?
Здесь много вполне правильных ответов, но я не думаю, что кто-то действительно решил исходное заблуждение. Исходный вопрос в основном звучит так: «Когда я создаю символическую ссылку, потом ее легко идентифицировать. Но я не могу понять, как определить жесткую ссылку». И да, ответы в основном сводятся к «вы не можете» и более или менее объясняют, почему, но, похоже, никто не признал, что на самом деле это сбивает с толку и странно.
Если вы читаете все это и поняли, что происходит, то у вас все в порядке; тебе не нужно читать мой кусочек. Если вы все еще в замешательстве, продолжайте.
По-настоящему краткий ответ заключается в том, что жесткая ссылка на самом деле вовсе не ссылка, не в том смысле, в каком является символическая ссылка. Это новая запись в структуре каталогов, которая указывает на ту же группу байтов, что и исходная запись в каталоге, и после того, как вы ее создали, она такая же «настоящая» и законная, как и первая. Каждый «нормальный» файл на вашем диске имеет хотя бы одну жесткую ссылку; без этого вы не увидите его ни в , ни в каталогах и не сможете ссылаться на него или использовать его. Итак, если у вас есть файл Fred.txt и вы жестко связываете с ним Wilma.txt и Barney.txt, все три имени (и записи каталога) относятся к одному и тому же файлу, и все они одинаково действительны. У ОС нет никакого способа сказать, что одна из записей была создана, когда вы нажимаете «сохранить» в текстовом редакторе, а остальные были сделаны с помощью команды «ln».
Однако операционная система должна отслеживать, сколько разных записей указывает на один и тот же файл. Если вы удалите Wilma.txt, неудивительно, что вы не освобождаете место на диске. Но если вы удалите Fred.txt («исходный» файл), вы все равно не освободите место на вашем диске, потому что данные на диске, который был известен как Fred.txt, по-прежнему также являются Barney.txt. Только при удалении всех записей каталога ОС освободит место, которое занимали сами данные.
Если бы Barney.txt был символической ссылкой, то удаление Fred.txt привело бы к освобождению места, и Barney.txt теперь был бы неработающей ссылкой. Кроме того, если вы переместите или переименуете файл, на который указывает символическая ссылка, вы разорвете ссылку. Но вы можете перемещать или переименовывать жестко связанный файл как хотите, не нарушая другие записи каталога, которые указывают на этот файл / данные, потому что все они являются записями каталога, которые относятся к одному и тому же блоку данных на диске (с помощью индексный номер этих данных).
[Прошло два года, и это последнее немного смутило меня на минуту, так что я думаю, что поясню. Если вы наберете «mv ./Wilma.txt ../elsewhere/Betty.txt», будет казаться, что вы перемещаете файл, но на самом деле это не так. На самом деле вы удаляете элемент строки из списка каталогов вашего текущего каталога, в котором говорится, что «имя 'Wilma.txt' связано с данными, которые можно найти с помощью индексного дескриптора ###### #, "и добавив новый элемент строки в список каталогов каталога ../elsewhere, в котором говорится, что" имя 'Betty.txt' связано с данными, которые можно найти через индексный дескриптор ####### ".Вот почему вы можете «переместить» 2-гигабайтный файл так же быстро, как 2-килобайтный файл, если вы перемещаете их в другое место на том же диске.]
Потому что ОС должна отслеживать, сколько разные записи каталога указывают на один и тот же фрагмент данных, вы можете определить, жестко ли связан конкретный файл, даже если вы не можете с уверенностью сказать, есть ли запись в каталоге, на которую вы смотрите является "оригинальным" или нет. Один из способов - это команда «ls», а именно «ls -l» (это строчная L после тире)
Заимствуем предыдущий пример ....
-rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f1
Первая буква - тире, поэтому это не каталог или что-то еще экзотическое, это обычный обычный файл. Но если бы это было действительно обыкновенно, то число после rwx-ish части было бы «1», например, «есть одна запись каталога, указывающая на этот блок данных». Но это часть демонстрации жестких ссылок, поэтому вместо этого написано «3».
Обратите внимание, что это может привести к странному и загадочному поведению (если вы еще не сосредоточились на жестких ссылках). Если вы откроете Fred.txt в текстовом редакторе и внесете некоторые изменения, вы увидите такие же изменения в Wilma.txt и Barney.txt? Может быть. Наверное. Если ваш текстовый редактор сохраняет изменения, открывая исходный файл и записывая в него изменения, то да, все три имени по-прежнему будут указывать на один и тот же (недавно измененный) текст. Но если ваш текстовый редактор создает новый файл (Fred-new-temp.txt), записывает в него вашу измененную версию, затем удаляет Fred.txt, а затем переименовывает Fred-new-temp.txt в Fred.txt, Вилма и Барни по-прежнему будут указывать на исходную версию, а не на новую измененную версию. Если вы не понимаете жестких ссылок, это может вас немного рассердить. :) [Хорошо, на самом деле я лично не знаю ни одного текстового редактора , который бы выполнял функцию нового файла / переименования,но я знаю множество других программ, которые делают именно это, так что будьте начеку.]
Последнее замечание: одна из вещей, которые проверяет fsck (проверка файловой системы), - это наличие блоков данных на вашем компьютере. диск, на который почему-то больше не ссылаются никакие записи каталога. Иногда что-то идет не так, и единственная запись каталога, указывающая на индексный дескриптор, удаляется, но само дисковое пространство не помечается как «доступное». Итак, одна из задач fsck - сопоставить все выделенное пространство со всеми записями каталога, чтобы убедиться, что нет файлов, на которые нет ссылок. Если он их находит, он создает новые записи каталога и помещает их в «потерянный + найденный».