Определение, является ли файл жесткой ссылкой или символьной ссылкой?

Сообщение поступает от src/core/manager.c в источниках systemd. Жестко закодировано использование уровня регистрации системы INFO.

По умолчанию systemd регистраций сообщения, имеющие уровень INFO, если вы можете изменить его, изменив /etc/systemd/system.conf на:

LogLevel=notice

, но вы также потеряете довольно много других информационных сообщений.

Лучше всего установить исправление src/core/manager.c , чтобы прочитать:

 log_struct(LOG_DEBUG,
            MESSAGE_ID(SD_MESSAGE_TIME_CHANGE),
            "MESSAGE=Time has been changed",
            NULL);

( LOG _ DEBUG определяется как следующий более высокий и самый высокий уровень в sys/syslog.h ), или прокомментировать

Я не нашел способ сообщить только об изменениях таймера, которые имеют минимальный размер X секунд. Но если это возможно, это, несомненно, сделает более сложным и подверженным ошибкам патч.

Этот код

awk '
  NR == FNR {feature[$1]=1; next} 
  $1 != "Name" {name[$1]=1; role[$1,$2]=1} 
  END {
    for (f in feature)
      printf "%-12s", f
    print ""
    for (n in name) { 
      for (f in feature) 
        printf "%-12s", (n SUBSEP f in role ? " " : n)
      print ""
    }
  }
' features roles 

дает этот выход

Lecturer    Student     Leader      

                        Bob         
Som                     Som         

достаточно близко?

С помощью операторов -h и -L команды test :

-h file 
true if file is a symbolic link

-L file 
true if file is a symbolic link

http://www.mkssoftware.com/docs/man1/test.1.asp

В соответствии с этим потоком SO они имеют одинаковое поведение, но предпочтителен -L .

Как правило, NIC прерывает работу CPU только в том случае, если ему необходимо отправить полученный пакет в систему. В неразборчивом режиме это будет только для пакетов, адресованных на его MAC-адрес, широковещательный адрес ff: ff: ff: ff: ff: ff, или многоадресный адрес, на который он подписан. Он также выполняет проверку перед отправкой пакета в CPU: обычная проверка CRC Ethernet и контрольные суммы IP/TCP/UDP, если NIC имеет эту возможность и драйвер включил эту разгрузку.

Некоторые сетевые карты имеют ограниченное количество адресов многоадресной подписки; если оно будет превышено, он отправит все многоадресные пакеты на CPU, и ОС должна отбросить те пакеты, которые ее не волнуют.

Можно установить только пакет telnet и использовать функции telnet-клиента. В качестве альтернативы можно использовать команду nc для проверки связности портов, если не следует связываться с telnet.

Пример:

$ touch f1
$ ln f1 f2
$ ln f1 f3
$ ln -s f1 s1
$ ln -s f2 s2
$ ln -s ./././f3 s3
$ ln -s s3 s4
$ ln s4 s5
$ ls -li
total 0
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f1
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f2
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f3
10802345 lrwxrwxrwx 1 stephane stephane 2 Nov 12 19:56 s1 -> f1
10802346 lrwxrwxrwx 1 stephane stephane 2 Nov 12 19:56 s2 -> f2
10802347 lrwxrwxrwx 1 stephane stephane 8 Nov 12 19:56 s3 -> ./././f3
10802384 lrwxrwxrwx 2 stephane stephane 2 Nov 12 19:56 s4 -> s3
10802384 lrwxrwxrwx 2 stephane stephane 2 Nov 12 19:56 s5 -> s3

Записи каталога f1 , f2 и f3 являются одинаковыми (один и тот же inode: 10802124, вы заметите, что число ссылок равно 3). Они представляют собой жесткие ссылки на один и тот же обычный файл.

s4 и s5 также являются одним и тем же файлом (10802384). Они имеют тип symlink , а не обычный . Они указывают на путь, здесь s3 . Поскольку s4 и s5 являются записями одного и того же каталога, этот относительный путь s3 точек к одному и тому же файлу (с inod 10802347) для обоих.

При выполнении команды ls -Ll появится запрос на получение информации о файле после разрешения символьных ссылок:

$ ls -lLi
total 0
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f1
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f2
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 f3
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 s1
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 s2
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 s3
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 s4
10802124 -rw-r--r-- 3 stephane stephane 0 Nov 12 19:55 s5

Все они разрешаются в один и тот же файл (10802124).

Можно проверить, является ли файл символьной ссылкой с помощью [-L-файл] . Аналогично, можно проверить, является ли файл обычным файлом с помощью [-f file] , но в этом случае проверка выполняется после разрешения символьных ссылок.

жесткие ссылки не являются типом файла, они являются просто разными именами для файла (любого типа).

Здесь много вполне правильных ответов, но я не думаю, что кто-то действительно решил исходное заблуждение. Исходный вопрос в основном звучит так: «Когда я создаю символическую ссылку, потом ее легко идентифицировать. Но я не могу понять, как определить жесткую ссылку». И да, ответы в основном сводятся к «вы не можете» и более или менее объясняют, почему, но, похоже, никто не признал, что на самом деле это сбивает с толку и странно.

Если вы читаете все это и поняли, что происходит, то у вас все в порядке; тебе не нужно читать мой кусочек. Если вы все еще в замешательстве, продолжайте.

По-настоящему краткий ответ заключается в том, что жесткая ссылка на самом деле вовсе не ссылка, не в том смысле, в каком является символическая ссылка. Это новая запись в структуре каталогов, которая указывает на ту же группу байтов, что и исходная запись в каталоге, и после того, как вы ее создали, она такая же «настоящая» и законная, как и первая. Каждый «нормальный» файл на вашем диске имеет хотя бы одну жесткую ссылку; без этого вы не увидите его ни в , ни в каталогах и не сможете ссылаться на него или использовать его. Итак, если у вас есть файл 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 - сопоставить все выделенное пространство со всеми записями каталога, чтобы убедиться, что нет файлов, на которые нет ссылок. Если он их находит, он создает новые записи каталога и помещает их в «потерянный + найденный».

вы можете использовать readlink FILE; эхо $? . Это возвращает 1, если это жесткая ссылка, и 0, если это символическая ссылка.

На странице руководства: «При вызове как readlink печатается только цель символьной ссылки. Если данный аргумент - - не является символической ссылкой, readlink ничего не напечатает. и выйдите с ошибкой. "

Мне это не помогло:

    if [ "$(stat -c %h -- "$file")" -gt 1 ]; then
        echo "File has more than one name."
    fi

У меня не получилось, пусть работает):

#!/bin/bash
if [ "$1" = "" ]
    then
        echo "Please enter command argument."
        exit;
fi
links=$(stat -c %h "$1" 2>/dev/null)
inode=$(stat -c %i "$1" 2>/dev/null)
if [ $links -gt 1 ]
    then
        echo "File has hard links, select directory to search...";
            PS3='Please enter your choice: '
            select opt in / /home Quit
do
    case $opt in
        "/")
           find / -inum $inode 2>/dev/null
           break
           ;;
        "/home")
           find /home -inum $inode 2>/dev/null
           break
           ;;
        "Quit")
           echo "Quit"
           break
           ;;
        *) echo "invalid option $REPLY"
           ;;
    esac

done

    else
        echo "File has no hard links"
fi