Чи вважаються жорсткі посилання звичайними файлами?

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

Мені це було цікаво, тому що я роблю сценарій bash, який повинен реєструвати файли як певні типи та приймати рішення відповідно. Це технічно не важливо для мого проекту, але мені було цікаво.

Крім того, якщо вони вважаються звичайними файлами, то чи існує спосіб перевірити, чи ці файли жорстко пов'язані без необхідності розбору ls -i? І чи є спосіб перевірити, чи якийсь довільний файл, X, важко пов'язаний з яким-небудь іншим довільним файлом, Y, без використання find -iкоманди?

У системах у стилі Unix структура даних, що представляє об'єкти файлової системи (іншими словами, дані про файл), зберігається у тому, що називається "inode".

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

lsКоманда покаже вам , скільки важко посилань є в файл.

Наприклад:

seumasmac@comp:~$ echo Hello > /tmp/hello.txt
seumasmac@comp:~$ ls -l /tmp/hello.txt 
-rw-rw-r-- 1 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

Тут ми створили файл під назвою /tmp/hello.txt. 1У висновку ls -lпоказує , що існує 1 жорстка посилання на цей файл. Це жорстке посилання - саме ім'я файлу /tmp/hello.txt.

Якщо ми зараз створимо ще одне тверде посилання на цей файл:

seumasmac@comp:~$ ln /tmp/hello.txt /tmp/helloagain.txt
seumasmac@comp:~$ ls -l /tmp/hello*
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/helloagain.txt
-rw-rw-r-- 2 seumasmac seumasmac 6 Oct  4 13:05 /tmp/hello.txt

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

seumasmac@comp:~$ ls -i /tmp/hello*
5374043 /tmp/helloagain.txt  5374043 /tmp/hello.txt

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

Якщо ми створимо каталог і зробимо це ls -ld:

seumasmac@comp:~$ mkdir /tmp/testdir
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 2 seumasmac seumasmac 4096 Oct  4 13:20 /tmp/testdir

Це показує, що до цього каталогу є 2 важких посилання. Це:

/tmp/testdir
/tmp/testdir/.

Зауважте, що /tmp/testdir/..це не посилання на цей каталог, це посилання на /tmp. І це говорить про те, чому працює "кількість підкаталогів". Коли ми створюємо новий підкаталог:

seumasmac@comp:~$ mkdir /tmp/testdir/dir2
seumasmac@comp:~$ ls -ld /tmp/testdir
drwxrwxr-x 3 seumasmac seumasmac 4096 Oct  4 13:24 /tmp/testdir

тепер ви можете бачити, що є три жорсткі посилання на /tmp/testdirкаталог. Це:

/tmp/testdir
/tmp/testdir/.
/tmp/testdir/dir2/..

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

Чи вважаються жорсткі посилання звичайними файлами?

Жорсткі посилання вважаються такими, з якими вони пов’язані. Ви можете зв’язати будь-що в одній файловій системі.

mkdir test
cd !$

>file
ln -s file sym
mknod pipe p

ln file file2
ln -P sym sym2
ln pipe pipe2

ls -al

# sockets, too:
cat >tsock.c <<\EOD
#include <sys/socket.h>
#include <sys/un.h>
int main(int n, char **a)
{
        struct sockaddr_un test = { AF_UNIX, "socket" };
        int testfd = socket(AF_UNIX, SOCK_SEQPACKET, 0);
        bind(testfd,(struct sockaddr *)&test,sizeof test);
}
EOD
make tsock
./tsock

ln socket socket2

ls -al

# even devices if you want:
sudo mknod mytty c 5 0
ln mytty mytty2
sudo chmod 666 mytty

ls -al
# notice permissions are on an object not on the links to it:
echo Hi, Kilroy! >mytty2  

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

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

Є (безлічі не unix) файлових систем, які не працюють таким чином, в тому числі такі, що називають те, що вони пропонують, як замінник "жорстких посилань". OS X збила еквівалент HFS + (який не має їх у початковому розумінні), якщо я пам'ятаю правильно, я не знаю, наскільки вірно він зберігає тут семантику.