Вопрос Как размер файла равен нулю?


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


173
2017-09-15 08:32


происхождения


имя файла не засчитывается в файл, как это можно объяснить. - njzk2
Мне напомнили друга в колледже, который написал часть программного обеспечения для хранения текста в виде имен файлов, чтобы обойти дисковые квоты. - slebetman
@ColeJohnson Я был стажером еще в 2000-х годах в одной из компьютерных лабораторий U, а пользовательская квота была рассчитана как сумма файлов. Поэтому хранение данных в виде имен файлов действительно обойдет qouta. Если вы можете сохранить программу в папки и это не будет считаться против вашей квоты. - Mindwin
@slebetman Это точка, где линия между гением и безумием становится размытой. - Pharap
Аналогичная техника была известна в проблема сжатия, - Oddthinking


ответы:


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

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


201
2017-09-15 08:34



... также известный как Hard Links. - Daniel B
В каталоге. В противном случае, если тот же файл был в двух каталогах, и вы переименовали его в один, который изменил бы другой каталог, который не имел бы никакого смысла. Кроме того, не так ли это, каково будет содержимое каталога ?! - David Schwartz
На большинстве UNIX-подобных ОС, таких как FreeBSD и Linux, вы можете легко получить размер каталога. Команды, подобные ls -ld <directory> будет работать. - David Schwartz
Я не знаю, верно ли это для текущей версии NTFS, но ранние версии (например, на NT3.x) будут хранить данные для очень маленьких файлов в записи каталога. Файл будет буквально не существовать. - John Rennie
Не совсем верно, что нет файла, если NTFS сильно отличается от других файловых систем. В обычной файловой системе Unix был бы inode, хранящий разрешения, mod-times и т. Д. Запись в каталоге по-прежнему относится к этому inode. Единственное различие между пустым файлом и непустым файлом - это указатель на выделение блоков. Пустой файл имеет эквивалент файловой системы указателя NULL для его карты блоков, хотя, чтобы указать, что у него нет каких-либо блоков данных. Записи каталога не загромождают разрешениями и модами, даже для пустых файлов. например, индексы XFS имеют значение 256B - Peter Cordes


Семантическое значение «размер файла» отличается от семантического.

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

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

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


82
2017-09-15 17:41



"в inode для каталога, содержащего файл" Разве вы не имеете в виду данные каталога, а не его индекс? Индекс содержит размеры файлов и даты, но не имена ... - Medinoc
@Medinoc Хорошая точка. Я думал о встроенном случае, когда он хранил данные в inode, но я на самом деле не проверял, насколько это может произойти! Я добавил редактирование. - Cort Ammon
Связанный встроенная функция данных из ext4, это ни в коем случае не является универсальным для всех файловых систем. Кроме того, это относится к файлам inode, а не к каталогу. Они являются отдельными, каталоги также имеют встроенные возможности данных, но они являются отдельными функциями. Индекс файлов имеет заданный размер, по крайней мере, в случае ext4, поэтому использование данных разрешений не имеет значения. Как правило, использование дискового пространства файлов зависит от используемой файловой системы, третья часть этого ответа применима только к ext4, насколько я могу судить, это не уточняется. - Phizes
Если у вас есть жесткий диск объемом 1 000 000 байт, возможно, пришло время подумать об обновлении. - nekomatic


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

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

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

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


53
2017-09-15 21:58



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


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

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

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


12
2017-09-16 14:59





(Немного поздно, чтобы ответить ...)

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

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

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

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

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

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

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

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

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

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

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

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


7
2017-09-16 09:55





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

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

enter image description here

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

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

enter image description here

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

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


4
2017-09-24 00:05





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

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

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


3
2017-09-16 09:41





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

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


1
2017-12-25 04:37





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


0
2017-09-16 18:55



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