Яка концепція створення файлу з нульовими байтами в Linux?

Якщо я виконую наступне:

touch /tmp/test

а потім виконуйте

ls -la /tmp/

Я міг бачити testфайл з 0 байтами в каталозі.

Але як операційна система обробляє концепцію 0 байт . Якщо я висловлюся це як мирянин:

0 Байт - це зовсім не пам'ять, тому нічого не створюється.

Створення файлу, повинно або має, принаймні, вимагати певної пам'яті, правда?

У файлі (приблизно) три окремі речі:

• "Inode", структура метаданих, яка відслідковує того, хто є власником файлу, дозволів та списку блоків на диску, які фактично містять дані.
• Одна або декілька записів каталогів (імена файлів), які вказують на цю дію
• Самі фактичні блоки даних

Коли ви створюєте порожній файл, ви створюєте лише вкладку і запис каталогу, що вказує на цю ділу. Те саме для розріджених файлів ( dd if=/dev/null of=sparse_file bs=10M seek=1).

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

Я тут спростив речі, але ви розумієте.

touchстворить індексний дескриптор , і ls -iчи statбуде відображатися інформація про инода:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

Зауважте, що testвикористовується 0 блоків. Для зберігання відображуваних даних inode використовує деякі байти. Ці байти зберігаються в таблиці inode. Подивіться на сторінку ext2 для прикладу структури inode .

ls(або добре, stat(2)системний виклик) повідомляє вам розмір вмісту файлу. Скільки місця потрібна файловій системі для ведення бухгалтерського обліку, це не є частиною цього, і, як детальна інформація про реалізацію, програми взагалі не повинні турбуватись або навіть знати про них. Зростання видимих ​​деталей про реалізацію зробить абстракцію файлової системи менш корисною.

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

Проста відповідь: Тому що це визначено саме так.

Більш довга відповідь: Це визначено таким чином, оскільки деякі операції концептуально простіші:

• Якщо файл містить 20 букв "А", а ви видалите всі "А", то файл стане на 20 байт коротшим. Та сама операція над файлом, яка складалася лише з "AAAAAAAAAAAAAAAAAAAAA", повинна мати справу з особливим випадком зникаючого файлу.
• Більш практично, видалення останнього рядка текстового файлу потребує спеціального обліку.
• Текстовим редакторам, які регулярно створюють резервну копію, потрібен спеціальний код для вирішення ситуації, коли користувач може видалити останній рядок, перейти до обіду, а потім повернутися та додати ще один рядок. Подальші ускладнення виникають, якщо деякі інші користувачі створили файл з цим іменем в середній час.

Ви можете зробити більше: * Файли журналу помилок, як правило, створюються порожніми, заповнюються лише тоді, коли трапляється помилка. * Щоб дізнатися, скільки помилок трапилось, ви рахуєте кількість рядків у файлах журналу. Якщо файл журналу порожній, кількість помилок дорівнює нулю, що має ідеальний сенс. * Іноді ви бачите файли, де весь відповідний текст є у назві файлу, наприклад this-is-the-logging-directory. Це не дозволяє адміністраторам надмірних видалень видаляти порожні каталоги після встановлення, а також запобігає помилкам, коли програма або користувач випадково створює файл, де програма хотіла б побачити каталог пізніше. gitПрограма (і інші) , як правило, ігнорують порожні каталоги, і якщо проект / адміністратор / користувач хоче мати запис про те , що каталог існує , навіть якщо він не має ніякого корисного змісту (поки), ви можете побачити порожній файл з ім'ямemptyабо empty.directory.

Жодні операції не ускладнюються:

• Зв’язування файлів: це просто неоперація з порожнім файлом.
• Пошук рядка у файлі: це стосується стандартного випадку "якщо файл коротший за пошуковий термін, він не може містити пошуковий термін".
• Читання з файлу: програми повинні мати справу з тим, щоб потрапити в кінець файлу, перш ніж вони отримали те, що очікували, тож знову ж таки справа файлу нульової довжини не передбачає додаткового мислення для програміста: він просто натисне в кінці -файл з початку.

Що стосується файлів, аспект "десь записаний файл" (inode та / або ім'я файлу) надходить до вищезазначених міркувань, але файлові системи не зробили б цього, якби порожні файли були марними.

Загалом, всі вищезазначені причини, крім тих, що стосуються імен файлів, стосуються послідовностей. Найбільш помітно для рядків, які є послідовностями символів: Рядки нульової довжини є звичайним явищем у програмах. Рядок зазвичай заборонено на рівні користувача, якщо вони не мають сенсу: ім'я файлу - це рядок, і більшість файлових систем не дозволяють порожній рядок як ім'я файлу; внутрішньо, створюючи імена файлів з фрагментів, програма цілком може мати порожній рядок як один із фрагментів.

Використовуючи найпростішу аналогію:

Порівняємо файл з, скажімо, склянкою води.

'touch / tmp / test' дуже схоже на створення порожнього келиха, без води у ньому. Склянка порожня, тому її розмір дорівнює нулю. Але скло все-таки існує.

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

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

Подумайте про це так: скажіть, що програма відстежує SQL запити, надіслані на ваш сервер. Програма хоче вказати, що вона записує запити в звичайний текстовий файл, але жодних запитів ще не записано. Як це має виглядати? Я б стверджував, що це повинен бути файл нульового розміру в /var/log/acme-sql-server/queries.log. Таким чином, ви могли зрозуміти, коли почався журнал (час створення файлу), коли він востаннє оновлювався (тобто коли він був створений), скільки запитів було записано (кількість нових рядків у файлі = 0) та хто робить журнал (Acme SQL Server). У таких випадках корисно мати концепцію порожнього файлу, який все-таки існує у певному місці.