Чи символічні посилання насправді впливають на використання диска?

Я читав на стільки веб-сайтах, що в Linux символічні посилання (м'які посилання, посилання) є подібно до покажчиків, які посилаються на інший файл, який може бути розміщений де завгодно (наприклад, ярлики Windows). Однак, коли я перевіряю використання диска папки, в якій є символічні посилання, виникає невідповідність між тим, що говорить мій файловий менеджер, і тим, що duзвітує. Однак якщо я набираю du -L( -L, --dereference; dereference all symbolic linksзі сторінки man), вихід du -Lі розмір, про який повідомляє мій менеджер файлів, однакові .

Моє запитання : якщо у мене є м'яке посилання на великий файл, наприклад, в моєму окремомуhomeрозділі, чи виникнуть у мене проблеми?

Приклад :

Моя /var/tmpпапка зараз просто порожня. Створимо файл:

$ cat /some/file.txt > file.txt
$ du -ac
164 ./file.txt
168 .
168 total

І мій менеджер файлів (Thunar, в даному випадку) звітує

Розмір: 1 предмет, загальною сумою 163,0 кБ

Гаразд. Тепер давайте створимо дійсно великий файл у /tmpта символьне посилання на нього:

$ cat /dir/really_big.txt > /tmp/heavy.txt
$ du -a | grep heavy.txt
408 ./heavy.txt
$ ln -s /tmp/heavy.txt heavy.txt
$ du -ac
164 ./file.txt
0   ./heavy.txt
168 .
168 total

На сьогодні все добре. Але якщо я відкрию свій файловий менеджер:

Розмір: 2 предмети, загальною вагою 570,3 кБ

І, нарешті:

$ du -acL
164 ./file.txt
408 ./heavy.txt
576 .
576 total

Якщо розділ, в якому /var/tmpзнаходиться, розміром 1 Гб, і я створюю в ньому посилання на файл 1 Гб, ¿чи загине мій жорсткий диск? Я знаю, що duвийде 168 та Thunar 1 GiB, але я не знаю, що правильно.

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

Звичайний duзвіт про простір, зайнятий деревом каталогів на диску. du -Lповідомляє про простір, який би зайняв дерево каталогів, якби всі символічні посилання були замінені їх цільовими. Перша - це зазвичай корисна інформація; наприклад, це простір, який ви відновите, якщо ви видалили дерево, і це (приблизно) простір, необхідний для резервного копіювання дерева.

duна дереві каталогів показано (як правило) трохи більше, ніж загальний розмір файлів. Це пов’язано з двома речами. По-перше, duтакож нараховується каталоги, у яких потрібно трохи місця для зберігання імен файлів та метаданих. По-друге, duпідраховує дисковий простір, який займає файл, який може відрізнятися від розміру файлу: найпоширеніший ефект полягає в тому, що файли займають ціле число блоків (4 кБ при типовій установці Linux), тому 1-байтовий файл може показувати як 4 кБ у дю виводі; але стиснення (наприклад, примітивна форма, надана рідкісними файлами майже в кожній файловій системі Unix), може зробити розмір файлу більшим, ніж його використання на диску.

З наведених цифр видно, що Thunar повідомляє про суму розмірів файлів у дереві каталогів, слідуючи символічним посиланням . Це насправді так тонко - це твердження, що загальний розмір становить 570,3 кБ, а не використання диска - 570,3 кБ. Що зовсім не видно з користувальницького інтерфейсу чи документації, це те, що при обчисленні розміру Thunar дотримується символічних посилань.

Хто з них "правильний" - це суб'єктивна справа. duповідомляє про використання диска. Thunar повідомляє про загальний розмір за символічними посиланнями. Створення символічного посилання має незначний вплив на використання диска, але за визначенням змінює загальні розміри-наступні-символічні посилання, про які повідомляє Thunar.

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

Щоб уточнити,

`du`    -> size of directory + size of all the softlinks  
`du -L` -> size of directory + size of all the files that the softlinks are pointing to.

Я не впевнений, чи це ви запитували, але якщо це так, то я вважаю, що це може бути відповіддю на ваше запитання.