Как размер файла может быть нулевым?


173

Просто то, с чем я столкнулся и не мог придумать правильного объяснения. Если я создаю пустой файл * .txt на моем компьютере, а затем смотрю на его размер, он показывает 0. Но как это возможно? Я имею в виду, что даже если сам файл пуст, он все равно должен иметь некоторый размер, чтобы хранить свое собственное имя. Как это можно объяснить? (Не зависит от ОС)


81
имя файла не учитывается в файле, как это можно объяснить.
njzk2

123
Мне вспоминается мой друг из колледжа, который написал программу для хранения текста в виде имен файлов, чтобы обойти дисковую квоту.
Slebetman

15
@ColeJohnson Я был стажером в 2000-х годах в одной из компьютерных лабораторий моего U, и пользовательская квота была рассчитана как сумма размеров файлов. Хранение данных в виде имен файлов действительно может обойти qouta. Черт возьми, вы можете сохранить программу в папках, и она не будет учитываться в вашей квоте.
Mindwin

20
@ Slebetman Это точка, где грань между гением и безумием становится размытой.
Pharap

10
Подобная техника была классно использована в сжатии ,
Странно,

Ответы:


202

Это возможно, потому что действительно нет файла. Там просто запись в каталоге с именем и владельцем. Запись каталога логически отличается от файла. Например, один и тот же файл может иметь более одного имени в нескольких каталогах.

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


30
... также известный как жесткие ссылки.
Даниэль Б

6
В каталоге. В противном случае, если один и тот же файл находится в двух каталогах и вы переименовали его в один, это изменило бы другой каталог, что не имело бы никакого смысла. Кроме того, если бы не этот путь, каким было бы содержимое каталога ?!
Дэвид Шварц

14
В большинстве UNIX-подобных ОС, таких как FreeBSD и Linux, вы можете легко получить размер каталога. Команды вроде ls -ld <directory>будут работать.
Дэвид Шварц

11
Я не знаю, верно ли это для текущей версии NTFS, но ранние версии (например, для NT3.x) сохраняли данные для очень маленьких файлов в записи каталога. Файл буквально не существует.
Джон Ренни

13
Не совсем верно, что файла нет, если только NTFS не сильно отличается от других файловых систем. В обычной файловой системе Unix был бы инод, хранящий разрешения, время модификации и так далее. Запись каталога все еще ссылается на этот индекс. Единственная разница между пустым файлом и непустым файлом заключается в указателе для выделения блоков. Пустой файл имеет файловую систему, эквивалентную NULL-указателю для своей карты блоков, однако, чтобы указать, что в нем нет блоков данных. Записи каталога не загромождены разрешениями и временем мода, даже для пустых файлов. например, XFS-иноды 256B
Питер Кордес,

82

Семантическое значение «размера файла» отличается от того, которое вы используете.

Есть много размеров файлов, которые имеют смысл. Наиболее распространенным, и тот, который вы видите здесь, является «количество байтов в файле». Если файл является пустым текстовым файлом, он может действительно содержать 0 байтов. Это число важно для программистов, потому что нам часто нужно открывать файл, «читать все данные» и закрывать его. Нам нужно знать, сколько байтов данных будет в файле, чтобы мы могли планировать заранее.

Другое значение вытекает из того, как большинство файловых систем хранят данные. Большинство файловых систем хранят данные в блоках. Например, файловая система может хранить данные в блоках по 64 КБ, что означает, что она никогда не выделит ничего, что не кратно 64 КБ. Это звучит неэффективно, но может сделать бухгалтерию намного проще, а часто проще, значит быстрее.

Третье значение, к которому вы обращаетесь, - это фактическое количество бит, необходимых на жестком диске для описания наличия файла. Это включает в себя информацию, которая обычно хранится отдельно от файла. Например, в Linux понятие «имя файла» хранится в inode для каталога, содержащего файл (edit: из комментариев, технически это хранится в данных каталога. Когда я писал это, я думал о маленьком -директория: данные размером менее 156 байт могут храниться непосредственно в inode). Это не часто используемое значение, потому что его очень трудно определить, не зная чрезвычайно глубокую внутреннюю работу вашей файловой системы (учли ли вы место, необходимое для хранения всех разрешений в файле?). Однако, если у вас есть жесткий диск на 1 000 000 байт,


2
"в inode для каталога, содержащего файл" Разве вы не имеете в виду данные каталога, а не его inode? Индод содержит размеры файлов и даты, но не содержит имен ...
Medinoc

@Medinoc Хороший вопрос. Я думал о встроенном случае, когда он сохранял данные в иноде, но на самом деле я не проверял, сколько это может произойти! Я добавил редактирование.
Cort Ammon

Связанная встроенная функция данных ext4, она ни в коем случае не универсальна для всех файловых систем. Кроме того, это относится к файлам inode, а не к каталогу. Они являются отдельными, каталоги также имеют встроенные возможности данных, но они являются отдельными функциями. Индекс файлов имеет заданный размер, по крайней мере, в случае ext4, поэтому использование разрешений для данных не имеет значения. Использование диска с файлами в значительной степени зависит от используемой файловой системы, третья часть этого ответа применима только к ext4, насколько я могу судить, это не ясно.
Фазы

8
Если у вас есть жесткий диск на 1 000 000 байт, возможно, пришло время подумать об обновлении.
nekomatic

53

Имя файла хранится где-то еще.

На вашем диске будет «файловая система», проще говоря, выберите способ представления и интерпретации имен и файлов на физическом диске.

На большинстве дисков Windows вы будете использовать файловую систему под названием «NTFS» (файловая система новой технологии), в которой информация о именах файлов хранится в основной таблице файлов (MFT) отдельно от содержимого файла. См. Статью в Википедии об основной таблице файлов .

Следовательно, сам файл будет иметь длину 0 байт, но его запись в MFT все равно будет занимать некоторое место.


11
а в случае NTFS размер файла, сообщаемый Windows и большинством инструментов, фактически равен размеру основного потока файла, который мы воспринимаем как содержимое файла. Файл, хранящийся в разделе NTFS, может дополнительно содержать некоторые данные, хранящиеся в альтернативных потоках данных , и при этом иметь размер сообщения 0 . Это хорошая функция файловой системы, чтобы узнать, хотите ли вы получить полную картину :)
Павел Булван,

12

Это довольно интересный онтологический вопрос ...

Сам файл является содержимым файла. Если файл не имеет содержимого, его размер равен нулю. Имя файла является такой же частью файла, как ваше собственное имя физически является частью вас (т. Е. Это не так).

Подобно тому, как ваше имя существует в голове (и вашей собственной) как идея, которая ссылается на / указывает на физическое вас, имя файла существует в дереве каталогов файловой системы и ссылается на / указывает на файл.


7

(С небольшим опозданием на ответ ...)

Как файл может иметь нулевой размер, немного сложнее, чем приведенные выше ответы. Вопрос помечен Win7, но рассмотрение других «более простых» файловых систем, таких как FAT или NTFS , может оказаться полезным, так как концепции похожи.

Диск не «знает», что такое файл и что такое каталог; это все данные в маленьких блоках. ОС различает значение блоков данных. Первые несколько особенные, но остальные блоки содержат либо информацию о данных (например: имя файла, длину файла, первый блок данных, содержащий данные), либо сами данные.

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

Когда вы «создаете» файл (скажем, с помощью touchкоманды UNIX ), ОС сначала создает запись в информационном блоке (каталоге) со следующим:

  • Name = My_File.txt
  • Длина = 0
  • Начальный блок данных = нет данных
  • Дополнительная информация (владелец, права доступа, дата создания / обновления / изменения) и т. Д.

Только если есть какие-то данные для «записи», он пытается найти пустой блок данных для хранения данных. Но блоки данных имеют фиксированный размер (скажем, 32 КБ), удобный для доступа к диску и чтения ОС. Если вы пишете только «Hello», большая часть блока является «пустой» (на самом деле это могут быть не нули, а мусор из того, что было раньше), поэтому таблица теперь также обновляет размер до длины (скажем, 5 символов + конец Файл), так что вы не получите плохие вещи.

Когда вы обновляете «файл» до длины> размера блока, ОС записывает данные в новый блок и обновляет блок данных, чтобы сказать, что файл продолжается в следующем блоке ПОСЛЕ первого (и так далее), а длина обновляется. новая длина (детали различаются).

В итоге вы получаете набор информационных блоков данных (каталогов или списков) с информацией о цепочках блоков данных (содержимом файлов).

Логически это также объясняет, почему перемещение файла в одной и той же файловой системе быстро мигает, а копирование занимает много времени. Операционная система должна только отредактировать 2 блока каталога, чтобы удалить запись из одного каталога (информационный блок данных) и добавить в другой. Удалить файл: просто удалите запись в блоке каталога, освобождая блоки данных файла для перераспределения.

ps: только то, что в карточном каталоге есть запись для книги, не означает, что она находится на полке (возможно, проверена или утеряна); размер файла 0.

pps: неправильно размещенная книга в библиотеке подразумевает библиотеку поиска или в терминах компьютера: chkdsk или repair disk!

Большее понимание можно почерпнуть, прочитав иноды UNIX или оценив, как системы контроля версий (ClearCase, TFS, Git и т. Д.) Управляют не только файлами и каталогами, но также версиями файлов и даже версиями каталогов. В большинстве случаев все хранится в базе данных и представляется пользователю в виде классической структуры каталогов и файлов!


4

У нас здесь есть несколько отличных ответов - я бы просто добавил версию с картинкой (тысяча слов и все такое).

Вот как выглядит один из моих жестких дисков в формате NTFS, если вы визуализируете его с помощью инструмента дефрагментации диска. MFT (Master File Таблица) показан в фиолетовый:

введите описание изображения здесь

Этот маленький фиолетовый квадрат описывает список файлов, присутствующих на моем HD. Грубо говоря, для диска NTFS это содержание книги; вместо страниц он указывает на их физическое местоположение на остальной части диска 1 .

Файл с нулевым байтовым размером может быть визуализирован как запись Оглавления, которая указывает на отсутствие страницы вообще:

введите описание изображения здесь

Запись есть в списке, но так как страница не указана, мы можем предположить, что контент не существует.

1 - Конечно, это немного сложнее, чем это; но такие вопросы, как карты секторов, зеркальные MFT и т. д., выходят за рамки этих вопросов.


3

Файловые системы хранят много информации о файле, такую ​​как имя файла, размер файла, время создания, время доступа, время изменения, созданный пользователь, права пользователя и группы, фрагменты, указатель на кластеры, в которых хранится файл, жесткие / программные ссылки, атрибуты ... Они называются файловыми метаданными . Почему вы учитываете эти метаданные в размере файла, когда пользователи не заботятся о них и не знают о них? Они действительно заботятся только о содержимом файла

Кроме того, каждая файловая система хранит различные типы метаданных, которые занимают различное количество места на диске. Например, разрешения POSIX сильно отличаются от разрешений NTFS, и inodeв POSIX также есть числа, которых нет в Windows. Даже файловые системы POSIX сильно различаются, например ext3 с 32-битным адресом блока, ext4 с 48-битным, Btrfs с 64-битным и ZFS с 128-битным адресом. Так как вы будете считать эти метаданные в размер файла?

Возьмем другой пример со 100-байтовым файлом, метаданные которого занимают 56 байтов в текущей файловой системе. Мы копируем файл в другую файловую систему, и теперь он занимает 128 байтов метаданных. Однако содержимое файла точно такое же , количество байтов в файлах также одинаково. Таким образом, отображение размера файла в системе как 156 байт, а в другом - 228 байт, очень запутанно и нелогично .


1

Размер файла 0, похож на высказывание: у меня есть бумага со 5словами на нем. А на другой бумаге на нем есть 0слова. Так что 0это вполне возможно.

Метаданные файла (время создания, время последнего изменения, владелец файла, права доступа) хранятся в другом месте и не включаются в размер файла.


0

Поймите это простым способом ... когда вы создаете файл ... создается сгенерированная запись каталога, которая работает как указатель на место в памяти файла, идентифицируемого по имени файла, которое вы предоставляете. Размер каталога увеличивается по мере того, как вы создаете все больше указателей или, скажем, файлов ... в то время как размер файла будет увеличиваться, только если вы поместите некоторые данные в указанное место, то есть в сам файл. До тех пор размер будет нулевым. :)


Это действительно комментарий, а не ответ, и он просто повторяет то, что говорили другие.
JakeGould

0

Так вот как это работает:

Как только вы создаете какой-либо файл на томе, он создает файловую запись в NTFS-файле mata, т.е. $ MFT (таблица основных файлов). Поскольку в MFT присутствует FRS (сегмент записи файла), вы увидите запись. Каждая файловая запись имеет размер 1 КБ по умолчанию в случае файловой системы NTFS. Но это пространство востребовано, только если вы храните некоторую информацию внутри файла. Даже если вы просто напишите одну букву «а», учитывая, что это текстовый файл, он будет занимать 1 КБ места, поскольку это размер FRS по умолчанию. Буква «а» идет к потоку данных по умолчанию и без имени этого FRS, $ Data, который является атрибутом, куда отправляются все ваши данные, если у вас нет ADS (альтернативного потока данных).

Дайте мне знать, если у вас возникнут вопросы.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.