Просто то, с чем я столкнулся и не смог придумать правильного объяснения. Если я создам пустой файл *.txt на своем ПК и затем посмотрю на его размер, он покажет 0. Но как это возможно? Я имею в виду, что даже если сам файл пустой, он все равно должен иметь какой-то размер, просто чтобы хранить свое имя. Как это можно объяснить? (Не зависит от ОС)
решение1
Это возможно, потому что на самом деле нет файла. Есть только запись каталога с именем и владельцем. Запись каталога логически отличается от файла. Например, один и тот же файл может иметь более одного имени в более чем одном каталоге.
К сожалению, термин «файл» не всегда используется для обозначения того же самого. Но логика размера файла исходит из модели, где запись каталога «прикрепляет» файл к каталогу, а имена файлов и связанные метаданные хранятся в каталоге.
решение2
Семантическое значение термина «размер файла» отличается от того, которое вы используете.
Существует много размеров файлов, которые имеют смысл. Самый распространенный из них, и тот, который вы видите здесь, — это «количество байтов в файле». Если файл — пустой текстовый файл, он действительно может содержать 0 байтов. Это число важно для программистов, поскольку нам часто нужно открыть файл, «прочитать все данные» и закрыть его. Нам нужно знать, сколько байтов данных будет в файле, чтобы мы могли планировать заранее.
Другое значение возникает из способа, которым большинство файловых систем хранят данные. Большинство файловых систем хранят данные в блоках. Например, файловая система может хранить данные в блоках по 64 КБ, то есть она никогда не выделит ничего, что не является четным кратным 64 КБ. Это звучит неэффективно, но это может значительно упростить бухгалтерский учет, а часто проще означает быстрее.
Третье значение, которое вы пытаетесь понять, — это фактическое количество бит, требуемых на жестком диске для описания наличия файла. Сюда входит информация, которая обычно хранится отдельно от файла. Например, в Linux концепция «имени файла» хранится в inode для каталога, содержащего файл (правка: из комментариев, технически это хранится в данных каталога. Когда я писал это, я думал о случае с небольшим каталогом. Данные размером менее 156 байт могут храниться непосредственно в inode). Это не часто используемое значение, потому что его ужасно трудно определить, не зная чрезвычайно глубоких внутренних механизмов вашей файловой системы (вы учитывали пространство, необходимое для хранения всех разрешений на файл?). Однако, если у вас жесткий диск на 1 000 000 байт, и вы хотите узнать, какой размер файла помещается на этом жестком диске, это будет для вас очень важным значением!
решение3
Имя файла хранится в другом месте.
На вашем диске будет «файловая система», проще говоря, метод выбора способа представления и интерпретации имен файлов и самих файлов на физическом диске.
На большинстве дисков Windows вы будете использовать файловую систему под названием «NTFS» (New Technology File System), которая хранит информацию об имени файла в главной таблице файлов (MFT) отдельно от его содержимого. См.Статья в Википедии о таблице основных файлов.
Таким образом, сам файл будет иметь длину 0 байт, но его запись в MFT все равно будет занимать некоторое место.
решение4
(Немного опоздал с ответом...)
Как файл может быть размером ноль, немного сложнее, чем указано в ответах выше. Вопрос помечен как Win7, но если рассматривать другие "более простые" файловые системы, такие какТОЛСТЫЙилиNTFS, может быть полезным, поскольку концепции схожи.
Диск не «знает», что такое файл, а что такое каталог; это все данные в маленьких блоках. ОС различает значение блоков данных. Первые несколько — специальные, но остальные блоки содержат либо информацию о данных (например, имя файла, длина файла, первый блок данных, содержащий данные), либо сами данные.
Каталог — это особый «файл», «данные» которого ОС понимает как информационный блок, содержащий информацию о файлах, а не содержимое файлов. Хорошей аналогией является физическая библиотека и карточный каталог. Представьте себе информационные блоки как карточный каталог, а полки — как блоки данных (карточный каталог также находится на структуре, похожей на полку).
Когда вы «создаете» файл (например, с помощью touchкоманды UNIX), ОС сначала создает запись в информационном блоке (каталоге) со следующим содержимым:
- Имя = Мой_Файл.txt
- Длина = 0
- Начальный блок данных = N/A
- Дополнительная информация (владелец, разрешения, дата создания/обновления/изменения) и т. д.
Только если есть какие-то данные для «записи», он пытается найти пустой блок данных для хранения данных. Но блоки данных имеют фиксированный размер (скажем, 32 КБ), что удобно для диска и для чтения ОС. Если вы пишете только «Hello», большая часть блока «пустая» (на самом деле это могут быть не нули, а мусор от того, что там было раньше), поэтому таблица теперь также обновляет размер до длины (скажем, 5 символов + конец файла), так что вы не получите плохих вещей.
Когда вы обновляете «файл» до длины, превышающей размер блока, ОС записывает данные в новый блок и обновляет блок данных, сообщая, что файл продолжается на следующий блок ПОСЛЕ первого (и так далее), а длина обновляется до новой длины (подробности различаются).
В итоге вы получаете набор информационных блоков данных (каталогов или списков) с информацией о цепочках блоков данных (содержимом файлов).
Логически это также объясняет, почему перемещение файла в той же файловой системе быстро мигает, а копирование занимает много времени. ОС нужно отредактировать только 2 блока каталогов, чтобы удалить запись из одного каталога (информационный блок данных) и добавить в другой. Удалить файл: просто удалить запись в блоке каталога, освободив блоки данных файла для перераспределения.
ps: Даже если в карточном каталоге есть запись о книге, это не значит, что она лежит на полке (возможно, взята из библиотек или утеряна); размер файла 0.
pps: Если книга затерялась в библиотеке, это подразумевает поиск в библиотеке или, выражаясь компьютерными терминами: chkdsk или восстановление диска!
Более глубокое понимание можно получить, прочитав об инодах UNIX или оценив, как системы контроля версий (ClearCase, TFS, Git и т. д.) управляют не только файлами и каталогами, но и версиями файлов и даже версиями каталогов. В большинстве случаев все хранится в базе данных и представляется пользователю в виде классической структуры каталогов и файлов!