Файлы нулевого размера

[ZimD]

Сегодня заметил, что на жёстком диске стало очень много файлов с размером 0 КБ. Этому недугу подверглись пока что только видео файлы большого размера.

Помогите пожалуйста разобраться почему так происходит? Что может вызвать такую ужасную ситуацию?

Я грешу на то что производил проверку диска встроенными средствамиСегодня заметил, что на жёстком диске стало очень много файлов с размером 0 КБ. Этому недугу подверглись пока что только видео файлы большого размера.

Помогите пожалуйста разобраться почему так происходит? Что может вызвать такую ужасную ситуацию?

Я грешу на то, что производил проверку диска встроенными средствами Вин. 10. На вирусы проверил - нету. СМАРТ диска тоже в порядке. Вин. 10. На вирусы проверил - нету. СМАРТ диска тоже в порядке.

[Smirnoff]

Цитата (ZimD) »

Вин. 10

Давай уточним ситуацию... у тебя Windows 10?

Цитата (ZimD) »

недугу подверглись пока что только видео файлы большого размера

"До того" эти файлы были адекватного размера, и видео из них показывалось плеерами?
Эти файлы были на несменном накопителе, или на внешнем?
"Быстрый запуск" в Win10 включён?

[9285]

Есть как минимум две основные причины такого (если речь идёт о NTFS):
- в записи файла в размере инициализированного стоит 0. (*)
- в атрибуте, отвечающем за расположение файла ест какие то ошибки, которые чекдиском обычно "лечатся" методом обрезания по самое не хочу.
(*) В этом случае, если поверх прежнего расположения файла ничего не записалось, есть шанс на то что после корректировки записи файл восстановится.
По любому, не лишним будет посмотреть что сделал чекдиск (в отношении записей проблемных файлов). Исходя из этого можно будет более точно понять в каком направлении "копать".

[ZimD]

Цитата (Smirnoff) »

Давай уточним ситуацию... у тебя Windows 10?

Совершено верно.

Цитата (Smirnoff) »

"До того" эти файлы были адекватного размера, и видео из них показывалось плеерами?

Так точно.

Цитата (Smirnoff) »

Эти файлы были на несменном накопителе, или на внешнем?

На стационарном месте системного блока.

Цитата (Smirnoff) »

"Быстрый запуск" в Win10 включён?

Да, галочки стоят, но не активны почему-то (нельзя отключить).

Добавлено через 3 минуты

Цитата (9285) »

Есть как минимум две основные причины такого (если речь идёт о NTFS):
- в записи файла в размере инициализированного стоит 0. (*)
- в атрибуте, отвечающем за расположение файла ест какие то ошибки, которые чекдиском обычно "лечатся" методом обрезания по самое не хочу.
(*) В этом случае, если поверх прежнего расположения файла ничего не записалось, есть шанс на то что после корректировки записи файл восстановится.
По любому, не лишним будет посмотреть что сделал чекдиск (в отношении записей проблемных файлов). Исходя из этого можно будет более точно понять в каком направлении "копать".

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

[9285]

Что касается логов чекдиска тот тут ты меня озадачил.
1. В каком то из журналов винды.
2. Бывает в подпапке Chkdsk папки System Volume Information - в данную папку не так просто зайти, но это и не обязательно - можно для этого использовать возможности программы DMDE, которой пригодится посмотреть что с записями проблемных файлов и ещё кое что.
Сейчас ещё остались файлы нулевых размеров?

[ZimD]

Цитата (9285) »

Что касается логов чекдиска тот тут ты меня озадачил.
1. В каком то из журналов винды.
2. Бывает в подпапке Chkdsk папки System Volume Information - в данную папку не так просто зайти, но это и не обязательно - можно для этого использовать возможности программы DMDE, которой пригодится посмотреть что с записями проблемных файлов и ещё кое что.
Сейчас ещё остались файлы нулевых размеров?

Программа Chkdsk была запущена в режиме чтения и записи.

Проверка файловой системы на E:
Тип файловой системы: NTFS.
Метка тома: DRV2.

Этап 1. Проверка базовой структуры файловой системы...


Обработано записей файлов: 119552. Проверка файлов завершена.


Обработано больших файловых записей: 4494.

Обработано поврежденных файловых записей: 0.
Этап 2. Проверка связей имен файлов...


Обработано записей повторного анализа: 8562.

Обработано записей индекса: 132126. Проверка индексов завершена.


Проверено неиндексированных файлов: 0.

Восстановлено неиндексированных файлов в утерянное и найденное: 0.

Обработано записей повторного анализа: 8562.
Этап 3. Проверка дескрипторов безопасности...
Проверка дескрипторов безопасности завершена.


Обработано файлов данных: 6288. CHKDSK проверяет журнал USN...


Обработано байт USN: 143253496. Завершена проверка журнала USN

Этап 4. Поиск поврежденных кластеров в данных пользовательских файлов...


Обработано файлов: 119536. Проверка содержимого файла завершена.

Этап 5. Поиск поврежденных и свободных кластеров...


Обработано свободных кластеров: 51172359. Проверка свободного места на диске завершена.

Windows проверила файловую систему и не обнаружила проблем.
Дальнейшие действия не требуются.

5723036 МБ всего на диске.
2524258 МБ в 66578 файлах.
163584 КБ в 6289 индексах.
0 КБ в поврежденных секторах.
354943 КБ используется системой.
65536 КБ занято под файл журнала.
3198272 МБ свободно на диске.

65536 байт в каждой единице распределения.
Всего единиц распределения на диске: 91568591.
Доступно единиц распределения на диске: 51172359.


Нашёл журнал :-) И файлы нулевого размера тоже оказывается остались :-/

[9285]

ZimD
Это лог, но только исправного тома а надо найти такой, в котором есть сообщения об исправлении ошибок типа таких, как на скриншоте.

[ZimD]

Цитата (9285) »

ZimD
Это лог, но только исправного тома а надо найти такой, в котором есть сообщения об исправлении ошибок типа таких, как на скриншоте.

Нашел и такой:

Такое подходит?
Программа Chkdsk была запущена в режиме чтения и записи.

Проверка файловой системы на E:
Тип файловой системы: NTFS.
Том отключен. ВCE ОТКРЫТЫЕ ДЕСКРИПТОРЫ ТОМА СТАЛИ НЕВЕРНЫ.
Метка тома: DRV2.

Этап 1. Проверка базовой структуры файловой системы...


Обработано записей файлов: 119552. Проверка файлов завершена.


Обработано больших файловых записей: 4494.

Обработано поврежденных файловых записей: 0.
Этап 2. Проверка связей имен файлов...


Обработано записей повторного анализа: 8562.

Обработано записей индекса: 132126. Проверка индексов завершена.


Проверено неиндексированных файлов: 0.

Восстановлено неиндексированных файлов в утерянное и найденное: 0.

Обработано записей повторного анализа: 8562.
Этап 3. Проверка дескрипторов безопасности...
Очистка от неиспользуемых индексных записей 72 в индексе $SII файла 0x9.
Очистка от неиспользуемых индексных записей 72 в индексе $SDH файла 0x9.
Очистка 72 неиспользованных дескрипторов безопасности.
Проверка дескрипторов безопасности завершена.


Обработано файлов данных: 6288. CHKDSK проверяет журнал USN...


Обработано байт USN: 143253320. Завершена проверка журнала USN

Этап 4. Поиск поврежденных кластеров в данных пользовательских файлов...


Обработано файлов: 119536. Проверка содержимого файла завершена.

Этап 5. Поиск поврежденных и свободных кластеров...


Обработано свободных кластеров: 51172360. Проверка свободного места на диске завершена.
В битовой карте тома обнаружено свободное место, помеченное как выделенное.

Windows сделала исправления в файловой системе.
Дальнейшие действия не требуются.

5723036 МБ всего на диске.
2524258 МБ в 66577 файлах.
163584 КБ в 6289 индексах.
0 КБ в поврежденных секторах.
354943 КБ используется системой.
65536 КБ занято под файл журнала.
3198272 МБ свободно на диске.

65536 байт в каждой единице распределения.
Всего единиц распределения на диске: 91568591.
Доступно единиц распределения на диске: 51172360.

[9285]

ZimD
Ошибки есть, но это обычные и не имеют отношения к проблеме.
А логи эти из журнала или из указанной папки (на том томе где проблемные файлы)? Если реально не делалось усечение атрибутов файлов, то возможен другой вариант о котором писал выше.
Пробовал работать с DMDE? Хочешь разобраться или как? Если хочешь - напишу как.

[ZimD]

Были обычные.
Поковырялся в E:\System Volume Information\Chkdsk и нашёл похоже то что надо - файл SpotFix20190302225523:
Проверка файловой системы на E:
Том отключен. ВCE ОТКРЫТЫЕ ДЕСКРИПТОРЫ ТОМА СТАЛИ НЕВЕРНЫ.
Метка тома: DRV2.

Проверка записей (158) о повреждениях...

Запись 1 из 158: Поврежденный файл "\Video\такой-то.mkv <0x3,0x49>" ... Флаг разреженности в атрибуте стандартной информации в файле 0x49
не должен быть задан.
Исправление сегмента 73 записи разреженного файла.
обнаружено и исправлено повреждение.

Запись 2 из 158: Поврежденный файл "\Video\Cartoon\такой-то.mkv <0x3,0x6c>" ... Флаг разреженности в атрибуте стандартной информации в файле 0x6c
не должен быть задан.
Исправление сегмента 108 записи разреженного файла.
обнаружено и исправлено повреждение.


и т.д. 158 аж. Заканчивается так:

Обработано записей о повреждениях: 158 за 32.1 с.

Windows исправила все обнаруженные ранее проблемы с этим диском.
Дальнейшие действия не требуются.

Добавлено через 1 минуту

Цитата (9285) »

ZimD
Хочешь разобраться или как? Если хочешь - напишу как.

Давайте разбираться почему так вышло?!)

[9285]

ZimD
Вот это то самое.
И вполне ожидаемое - разреженные файлы. Учитывая что это файлы видео, то предположу что скачаны через торренты. А некоторые клиенты изначально записывают их на диск мелкими фрагментами и (что более странно) делают их разреженными. это и приводит к тому что файл имеет ооооооооочень большое число фрагментов, описание расположения которых требует огромное число записей MFT. Если в базовой записи не хватает места для перечисления всех записей, используется расширенный атрибут, в котором перечисляются все записи.
В случае повреждения любой из этих составляющей из них вся эта "цепочка" нарушается и чекдиск "фиксит" всё это таким образом.
И тут остаётся только понять что же случилось - а вот с этим скорей всего облом, потому как надо иметь то, что было до правки чекдиском. Хотя, а вдруг у тебя имеется образ тома Е до фикса?

[9285]

Даже если и нет предшествующего состояния можно всё таки посмотреть как выглядят записи повреждённых файлов, в том числе и уже удалённых (если они ещё не перезаписались чем то новым.
Итак
1. Запускаешь программу DMDE (GUI версия удобней).
2. В окне выбора можешь сразу выбрать логический диск (я так понимаю Е) и на последующем окне Разделы выбрать том и открыть его.
3. В открытом томе, переходишь в правое верхнее окно и заходишь в папку Root а далее продвигаясь по структуре папок находишь нужный файл. Можно и не бродить по папкам а воспользоваться поиском по типу (имени) файла.
3. Когда найдёшь проблемный файл, выдели его и нажми Ctrl+Enter (или в контекстном меню выбери "Открыть файл MFT (диск.редактор)
И смотри на содержимое окна ниже. Интересует наличие среди нескольких атрибутов 20-го - это и есть расширенный атрибут. Выделяешь его и нажимаешь пробел - список раскроется и в нём видно какая структура этого расширенного атрибута (бывает двух типов).
Можешь сделать аналогичное и на тех файлах, которые не потеряли размер.
В случае если хочется посмотреть запись удалённого файла, то надо сделать Виртуальную реконструкцию, после которой станут видны и удалённые файлы (с характерным значком корзины).

На скриншоте я выделил цветом на что стоит обратить внимание:
красным выделен значок удалённого файла
зелёным - номер файловой записи
филетовым - номер атрибута
коричневым - открытый 20-й атрибут

Хинт. В логе чекдиска фигурируют номера исправленных записей.
В твоём - в шестнадцатиричном виде, хотя могут и в десятичной (иногда даже в одной строке бывает что и так и так). Шестнадцатиричные можно определить по 0х в начале (например "в файле 0x6c").
Переводишь шестнадцатиричное в десятичное и получаешь 0x6c = 108
Зная номер исправленного файла можно не искать его в структуре папок а просто перейти к нужной записи. Для этого в меню Редактор выбираешь "Файловая запись" или просто нажимаешь Alt+F, вбиваешь нужный номер записи и переходишь к ней..

[ZimD]

Предположение насчёт торентов указанных файлов верное, хотя, если не ошибаюсь не всех. По-моему некоторые обнуленные файлы были перекинуты с диска на диск.
Образа диска к увы нету, ведь это самый большой из имеющихся у меня жёстких дисков - на 6 ТБ.
Можно ли что-то сделать чтобы в будущем такое не повторилось?

[garniv]

Цитата (ZimD) »

Можно ли что-то сделать чтобы в будущем такое не повторилось?

Чтобы минимизировать фрагментацию закачиваемых файлов, нужно в настройках торрент-клиента выбрать опцию предварительного резервирования места для файлов. Я так понял что в этом случае торрент-клиент перестает использовать разреженные (sparse) файлы https://qbforums.shiki.hu/index.php?topic=2908.0

Цитата (Dayman) »

sparse is enabled when preallocation is off

Наверное так и в остальных клиентах. Но например в uTorrent можно проверить состояние флага diskio.sparse_files в разделе дополнительных настроек.

Я использую Vuze, и там переключатель предварительного резервирования места для файлов находится в меню Tools -> Options -> Files -> Allocate and zero new files on creation. Если у вас uTorrent - посмтрите в Options -> Preferences -> General -> Preallocate all files

Ну и можно рискнуть сделать дефрагментацию существующих файлов (торрент на это время лучше не запускать). /рискнуть - потому что непонятна причина повреждений в MFT/

[9285]

ZimD
Сами по себе, разреженные файлы "выглядят" как расчёска и когда ты производишь запись на диск с таковыми, то и новые данные записываются в промежутки между, что приводит и к их фрагментации.
Насчёт новых торрентов читай совет garniv, что касается уже записанных, то я не знаю дефрагментатора, который бы позволял избавится от расширенного атрибута - все, с какими доводилось сталкиваться сами данные могут собрать в единый блок, и даже данные расположения в одной записи собирают в одну, но вот саму кучу этих записей нет. И в плане ненадёжности этой конструкции ничего не изменяется.
Если на диске есть достаточно свободного места, то могу лишь предложить следующее. Если торент клиент работает - заверши его. Всё таки сделай дефрагментацию - это чтобы данные файлов просто собрались в одно место.
Ну а потом скопируй файл (ы) в другую папку, старый удали а на его место верни скопированный.
Тут только есть одна закавыка - что за диск у тебя? Если с SMR то даже не знаю стоит ли такое делать - точнее на сколько дней это может затянуться.
PS. Не факт что есть вина быстрого запуска, но от этой гадости лучше отказаться.

[ZimD]

Цитата (9285) »

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

Спасибо за подробное описание. Думаю получилось, то что надо. Вот только не понимаю что это значит теперь:

[ZimD]

Цитата (garniv) »

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

Спасибо, включил в qBittorent опцию, которая так и называется.

Добавлено через 11 минут

Цитата (9285) »

ZimD
Тут только есть одна закавыка - что за диск у тебя? Если с SMR то даже не знаю стоит ли такое делать - точнее на сколько дней это может затянуться.
PS. Не факт что есть вина быстрого запуска, но от этой гадости лучше отказаться.

Диск WD Blue WD60EZRZ На https://www.wd.com/ru-ru/products/in...e-desktop.html не нахожу данных о таком параметре. Может как-то программно узнать?
Подскажите еще пожалуйста как избавиться от этой гадости?) У меня почему-то не активны эти галочки (быстрый запуск включён, но отжать нельзя).

[9285]

ZimD
На моём скриншоте был вариант простого расширенного атрибута, к котором данные о дополнительных записях хранятся в базовой записи.
На твоём другой вариант при котором число указателей записей больше, чем можно записать в одной записи, поэтому эти данные выносятся в отдельный список, на который указывается в основной записи. Конкретно для этой записи - список расположен в кластере 42311 и там должен быть список из 5ти записей. Но думаю что там списка нет (*) но лучше посмотреть. Для этого нужно навести на строку где виден номер этого кластера и нажать Enter - когда произойдёт переход, смотри в статусной строке какой номер кластера.
Другой вариант перехода - в меню Редактор выбрать Кластер (Alt+C) и ввести указанный номер.
(*) Учитывая что чекдиск "исправил" ошибки, то если даже список был цел, а ошибки были в других "звеньях цепочки" то при "испралении" список мог быть и очищен.

Можно ли программно определить SMR - не знаю. Разве что загонять тест с длительной записью в результате чего, через некоторое время, скорость записи должна резко сократится.
А так, смотреть спецификацию в части плотности записи, и опопсредованно можно
определить по размеру кэша. Учитывая что у твоего 64мб, то это обычный диск.

Цитата

У меня почему-то не активны эти галочки (быстрый запуск включён, но отжать нельзя).

Там нужно выбрать "Изменение параметров которые недоступны сейчас", после чего можно будет снять галку.

Добавлено через 1 час 10 минут

Что касается самого усечения и выявления причины такового.
Для начала посмотреть данные списка и если там будет что то относящееся к нему, то смотреть далее сами записи перечисленные в списке - возможно что какая то из них повреждена.
Если не исключать вариант проблем из за быстрого запуска и ситуации типа как в после CHKDSK не видно фалов(win10), то можно попробовать определить была ли перезапись начальных записей, которая могла привести к отсечению части записей, в которых могли быть и те, которые относились с проблемным файлам.
В общем то, всё зависит от твоего желания со всем этим разбираться.

[ZimD]

Цитата (9285) »

ZimD
Там нужно выбрать "Изменение параметров которые недоступны сейчас", после чего можно будет снять галку.

спасибо, выключил быстрый запуск

[ZimD]

Цитата (9285) »

ZimD
На моём скриншоте был вариант простого расширенного атрибута, к котором данные о дополнительных записях хранятся в базовой записи.
На твоём другой вариант при котором число указателей записей больше, чем можно записать в одной записи, поэтому эти данные выносятся в отдельный список, на который указывается в основной записи. Конкретно для этой записи - список расположен в кластере 42311 и там должен быть список из 5ти записей. Но думаю что там списка нет (*) но лучше посмотреть. Для этого нужно навести на строку где виден номер этого кластера и нажать Enter - когда произойдёт переход, смотри в статусной строке какой номер кластера.
Другой вариант перехода - в меню Редактор выбрать Кластер (Alt+C) и ввести указанный номер.
(*) Учитывая что чекдиск "исправил" ошибки, то если даже список был цел, а ошибки были в других "звеньях цепочки" то при "испралении" список мог быть и очищен.

Прошу прощения если сделал не то, что следовало. Для меня эти данные тёмный лес, но надеюсь, что получилось: