Як розмір файлу може дорівнювати нулю?

Просто я щось наткнувся і не міг придумати належного пояснення. Якщо я створюю на своєму ПК порожній файл * .txt, а потім переглядаю його розмір, він показує 0. Але як це можливо? Я маю на увазі, навіть якщо сам файл порожній, він все одно повинен мати певний розмір, просто для збереження власного імені. Як це можна пояснити? (Не специфічно для ОС)

Це можливо, тому що насправді немає файлу. Там просто запис каталогу з іменем та власником. Запис у каталозі логічно відрізняється від файлу. Наприклад, один і той же файл може мати більше одного імені у більш ніж одній директорії.

На жаль, термін «файл» не завжди вживається для того, щоб означати саме те саме. Але логіка розміру файлу походить від моделі, де запис каталогу "приєднує" файл до каталогу, а імена файлів та пов'язані з ними метадані зберігаються в каталозі.

Семантичне значення "розмір файлу" відрізняється від того, яке ви використовуєте.

Існує багато розмірів файлів, які мають сенс. Найбільш поширений і той, якого ви бачите тут, - це "кількість байтів у файлі". Якщо файл - це порожній текстовий файл, він дійсно може містити 0 байт. Це число важливе для програмістів, оскільки нам часто потрібно відкрити файл, "прочитати всі дані" та закрити його. Нам потрібно знати, скільки байтів даних буде у файлі, щоб ми могли планувати заздалегідь.

Ще одне значення виникає з того, як більшість файлових систем зберігають дані. Більшість файлових систем зберігають дані в блоках. Наприклад, файлова система може зберігати дані в 64 кБ блоків, тобто ніколи не виділяє нічого, що не є кратним 64 кБ. Це звучить неефективно, але це може зробити бухгалтерський облік досить простішим, а часто і простішим засобом швидше.

Третім значенням, яке ви тужите, буде фактична кількість бітів, необхідних на жорсткому диску, щоб описати наявність файлу. Сюди входить інформація, яка зазвичай зберігається окремо від файлу. Наприклад, в Linux поняття "ім'я файлу" зберігається в inode для каталогу, що містить файл (редагувати: з коментарів, технічно це зберігається в даних каталогу. Коли я писав це, я думав про маленьке Дані, що мають менше 156 байтів, можуть зберігатися безпосередньо в inode). Це не є загальновживаним значенням, оскільки це важко визначити, не знаючи надзвичайно глибоких внутрішніх функцій вашої файлової системи (ви враховували простір, необхідний для зберігання всіх дозволів на файл?). Однак якщо у вас жорсткий диск на 1 000 000 байт,

Ім'я файлу зберігається десь в іншому місці.

Ваш диск буде мати "файлову систему" на ньому, просто кажучи про метод вибору представлених і інтерпретованих на фізичному диску імен та файлів на фізичному диску.

На більшості дисків Windows ви будете використовувати файлову систему під назвою "NTFS" (Нова технологічна файлова система "). Ця інформація зберігає файли в таблиці головних файлів (MFT) окремо від вмісту файлу. Дивіться статтю Вікіпедії в таблиці головних файлів .

Таким чином, сам файл буде довжиною 0 байт, але його запис у MFT все ще займе місце.

Це досить цікаве онтологічне питання ...

Сам файл - це вміст файлу. Якщо файл не має вмісту, він має розмір нуля. Ім'я файлу - це стільки ж частини файлу, скільки ваше власне ім’я фізично є частиною вас (тобто, це не так).

Так само, як ваше ім'я існує як ідея в головах людей (і вашої власної), яка посилається / вказує на фізичну ви, ім'я файлу існує в дереві каталогів файлової системи, і воно посилається / вказує на файл.

(Трохи пізно до відповіді ...)

Як розмір файлу дорівнює нулю, трохи складніше, ніж передбачено вищезазначеними відповідями. Питання позначене Win7, але перегляд інших "простіших" файлових систем, таких як FAT або NTFS , може бути корисним, оскільки поняття схожі.

Диск не "знає", що таке файл, а що - каталог; це всі дані в маленьких блоках. В ОС розрізняють значення блоків даних. Перші кілька спеціальних, але решта блоків містять або інформацію про дані (наприклад: ім'я файлу, довжину файлу, перший блок даних, що містить дані), або самі дані.

Каталог - це спеціальний "файл", "дані" якого ОС розуміє, це інформаційний блок, що містить інформацію про файли, а не вміст файлів. Доброю аналогією є фізична бібліотека та каталог карт. Розгляньте інформаційні блоки як каталог картки, а полички - як блоки даних (каталог карт також розташований на структурі, подібній до полиць).

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

• Ім'я = My_File.txt
• Довжина = 0
• Початок блоку даних = N / A
• Додаткова інформація (власник, дозволи, створена / оновлена ​​/ змінена дата) тощо

Тільки за наявності деяких даних для "запису" вона намагається знайти порожній блок даних для зберігання даних. Але блоки даних поставляються у фіксованих розмірах (скажімо, 32 К), зручних для диска, щоб дістатись та ОС читати. Якщо ви пишете лише "Привіт", більша частина блоку "порожня" (насправді це можуть бути не нулі, але сміття з того, що було раніше), тож таблиця також тепер оновлює розмір на довжину (скажімо, 5 символів + Кінець Файл), щоб ви не отримали поганих речей.

Коли ви оновлюєте "файл" на довжину> розмір блоку, ОС записує дані в новий блок і оновлює блок даних, щоб сказати, що файл продовжується на наступний блок ПІСЛЯ першого (і так далі), а довжина оновлюється нова довжина (деталі відрізняються).

У кінцевому підсумку - це набір інформаційних блоків даних (каталогів або списків) з інформацією про ланцюги блоків даних (вміст файлу).

Логічно це також пояснює, чому переміщення файлів у тій же файловій системі блимає швидко, тоді як копія займає тривалий час. ОС має лише редагувати 2 блоки каталогів, щоб видалити запис з одного каталогу (блок інформації) та додати до іншого. Видалити файл: просто видаліть запис у блоці каталогу, звільнивши блоки даних файлів, які потрібно перерозподілити.

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

pps: Неправильно розміщена книга всередині бібліотеки передбачає пошук бібліотеки або в комп'ютерному відношенні: chkdsk або ремонт диска!

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

У нас є кілька чудових відповідей - я просто додам версію картинки (тисяча слів і все таке.)

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

Цей маленький фіолетовий квадрат описує список файлів у моєму HD. Приблизно, для диска NTFS - це зміст книги; замість сторінок вказує на їх фізичне розташування на решті диска ¹ .

Файл з нульовим байтом можна візуалізувати як запис Змісту, який вказує на відсутність сторінки:

Запис є там, перерахований - але оскільки жодна сторінка не вказана, ми можемо вважати, що вміст не існує.

^{1 - Безумовно, це трохи складніше, ніж це; але такі сфери, як картки секторів, дзеркальні MFT тощо, виходять за рамки цих питань.}

Файлові системи зберігають багато інформації про такий файл, як ім'я файлу, розмір файлу, час створення, час доступу, модифікований час, створені користувацькі, користувацькі та групові дозволи, фрагменти, вказівник на кластери, що зберігають файл, жорсткі / м'які посилання, атрибути ... Вони називаються метаданими файлів . Чому ви зараховуєте ці метадані до розміру файлу, коли користувачі не потребують (а) їх піклуються та не знають про них? Їх цікавить лише вміст файлу

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

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

Розмір файлу 0, схожий на вислів: У мене є папір зі 5словами. А на іншому папері в ньому є 0слова. Так 0цілком можливо.

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

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

Ось так це працює:

Як тільки ви створюєте будь-який файл на томі, він створює файловий запис у матовому файлі NTFS, тобто $ MFT (Основна таблиця файлів). Оскільки в MFT є FRS (сегмент запису файлів), ви побачите запис. У випадку файлової системи NTFS кожен файл за замовчуванням має розмір 1 Кб. Але цей простір вимагається лише в тому випадку, якщо ви зберігаєте деяку інформацію всередині файлу. Незважаючи на те, що ви просто пишете одну букву "а", враховуючи, що це текстовий файл, він вимагатиме 1 Кб місця, оскільки це розмір FRS за замовчуванням. Буква "а" переходить до потоку даних за замовчуванням і без назви цього FRS, $ Data - атрибут, куди потрапляють усі ваші дані, якщо у вас немає ADS (альтернативного потоку даних).

Повідомте мене, якщо ви поставите будь-які запитання.

• Для отримання додаткової інформації про зростання файлів NTFS .
• Більше інформації про метафіли NTFS .