Какова концепция создания файла с нулевым байтом в Linux?

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

Используя простейшую аналогию:

Давайте сравним файл, скажем, с стакан воды.

'touch / tmp / test' очень похож на создание пустого стакана без воды. Стакан пустой, поэтому его размер равен нулю. Но стекло существует.

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

Могут быть полезны файлы нулевого размера. Один из примеров - использование их в качестве навигационной крошки, где простое существование может использоваться для обозначения какого-то состояния (то есть, если файл существует: тогда что-то сделайте; если нет: игнорировать).

Простой ответ: Потому что так определено.

Более длинный ответ: Он определен так, потому что некоторые операции концептуально проще:

• Если файл содержит 20 букв "A", и вы удалите все "A", то файл станет на 20 байт короче. Та же операция с файлом, состоящим из одних "AAAAAAAAAAAAAAAAAAAAAAAAAA", должна была бы иметь дело с особым случаем исчезающего файла.
• В более практическом плане удаление последней строки текстового файла должно иметь особый случай.
• Текстовые редакторы, которые регулярно делают резервную копию, нуждаются в специальном коде, чтобы справиться с ситуацией, когда пользователь может удалить последнюю строку, пойти на обед, затем вернуться и добавить еще одну строку. Дополнительные сложности возникнут, если за это время другие пользователи создадут файл с таким именем.

Вы можете сделать больше: * Файлы журнала ошибок обычно создаются пустыми, чтобы быть заполненными, если и только если произойдет ошибка. * Чтобы узнать, сколько ошибок произошло, подсчитайте количество строк в файлах журнала. Если файл журнала пуст, количество ошибок равно нулю, что вполне логично. * Иногда встречаются файлы, где весь необходимый текст содержится в имени файла, например, this-is-the-logging-directory. Это предотвращает удаление пустых каталогов после установки нерадивыми администраторами, а также предотвращает ошибки, когда программа или пользователь случайно создает файл там, где программа хотела бы видеть каталог позже. Программа git (и другие) склонна игнорировать пустые каталоги, и если проект/администратор/пользователь хочет иметь запись о том, что каталог существует, даже если в нем нет полезного содержимого (пока), вы можете увидеть пустой файл с именем empty или empty.directory.

Никакие операции не усложняются:

• Конкатенация файлов: это просто no-op с пустым файлом.
• Поиск строки в файле: это покрывается стандартным случаем "если файл короче поискового запроса, то он не может содержать поисковый запрос".
• Чтение из файла: программы должны иметь дело с попаданием в конец файла до того, как они получили то, что ожидали, поэтому опять же случай файла нулевой длины не требует дополнительных размышлений для программиста: он просто попадет в конец файла с самого начала.

В случае с файлами аспект "где-то записан файл" (инод и/или имя файла) накладывается на вышеприведенные соображения, но файловые системы не стали бы этого делать, если бы пустые файлы были бесполезны.

В общем, все вышеперечисленные причины, кроме тех, что относятся к именам файлов, применимы к последовательностям. В первую очередь к строкам, которые представляют собой последовательности символов: Строки нулевой длины - обычное явление внутри программ. Строки обычно запрещаются на уровне пользователя, если они не имеют смысла: имя файла - это строка, и большинство файловых систем не допускают пустую строку в качестве имени файла; внутри программы, при создании имен файлов из фрагментов, в качестве одного из фрагментов вполне может быть пустая строка.

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

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 блоков. Для хранения отображаемых данных индекс использует несколько байтов. Эти байты хранятся в таблице инодов. Посмотрите на странице ext2 пример структуры inode .

ls(или хорошо, stat(2)системный вызов )сообщает вам размер содержимого файла. Сколько места требуется файловой системе для ведения бухгалтерского учета, это не является частью этого, и как деталь реализации это не то, что программы в целом должны заботиться или даже знать об этом. Отображение деталей реализации сделало бы абстракцию файловой системы менее полезной.