Файлы usn что это

Обновлено: 07.07.2024

Команда fsutil USN используется для опроса и управления журналом изменений NTFS Change Journal на указанном томе. Многие не подозревают о существовании такого журнала, так как это достаточно новая (появившаяся только в Windows 2000 и более поздних версиях) возможность файловой системы.

В основном журнал изменений (Change Journal) оказывается полезным для программ резервного копирования, так как позволяет ускорить процесс инкрементного резервного копирования. В операционных системах Windows, которые существовали до появления Windows 2000, при выполнении инкрементного копирования сканировался весь том, что позволяло составить список файлов, изменившихся с момента последнего резервного копирования.

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

Все эти проблемы были исправлены в момент появления журнала изменений NTFS. Использование Change Journal позволяет операционной системе поддерживать собственный индекс файлов и записывать изменения с помощью номеров последовательности обновления (Update Sequence Number — USN). Даже изменения в имени файла или в списке прав доступа записываются в журнал изменений. Приложения резервного копирования, которые по настоящему совместимы с Windows 2000 и более поздними версиями операционной системы Windows, могут использовать Change Journal.

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

Кроме программ для резервного копирования Change Journal используется следующими службами Windows:

  • Служба репликации файлов (File Replication Services)
  • Служба индексирования (Indexing Service)
  • Служба удаленной установки (Remote Installation Service)
  • Служба удаленного хранения (Remote Storage Service)

В частности, команда fsutil USN позволяет выполнять следующие административные операции по отношению к тому с включенным Change Journal:

  • Создавать новый Change Journal
  • Вносить изменения в существующий Change Journal
  • Отображать список записей Change Journal между определенными значениями USN
  • Получать общую информацию о Change Jounal (вместимость, информацию о записях)
  • Отображать данные USN для определенного файла

Эти задачи выполняются с помощью такого синтаксиса команды fsutil USN:

Несложно заметить, что существует несколько вариантов этой команды. Параметры каждой версии команды рассматриваются в следующей таблице.

Параметры команды fsutil USN

Создает новый Change Journal на указанном томе. Если такой журнал уже существует, параметры Change Journal меняются на указанные в команде

Используется для указания максимального размера журнала (в байтах) для выделения дискового пространства для Change Journal

Используется для указания объема данных (в байтах), которые должны быть удалены в начале и добавлены в конец Change Journal. Другими словами, как только Change Journal достигнет максимального размера указанный этим параметром объем старых данных будет стерт для освобождения места новым данным

Используется для указания буквы диска или пути монтирования интересующего тома

Используется для отключения активного Change Journal

Существуют два флага команды fsutil USN deletejournal:

  • /d — отключает активный Change Journal с возвратом управления вводом/выводом системе до завершения операции отключения.
  • /n — отключает активный Change Journal с возвратом управления вводом/выводом системе после завершения операции отключения.

Перечисляет данные Change Journal между двумя указанными точками

Указывает ординальную позицию файла, в которой начинается перечисление

Указывает нижнюю границу записей USN в Change Journal, которые возвращаются в выводе команды

Указывает верхнюю границу записей USN в Change Journal, которые возвращаются в выводе команды. Файлы, USN которых равны или попадают в интервал от LowUSN до HighUSN, возвращаются командой

Используется для отображения конфигурационной информации Change Journal. Эта информация содержит первый USN, максимальный размер журнала и разность выделения

Используется для отображения данных USN для определенного файла

Используется для указания полного пути к файлу, который должен быть проверен с помощью команды fsutil USN readdata

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

В этом случае необходимо или чаще выполнять инкрементное резервное копирование или увеличить размер Change Journal. Предположим, что для обеспечения корректности резервного копирования необходимо увеличить размер Change Journal до 500МВ. Кроме этого, старые данные должны замещаться новыми порциями по 5МВ. Перед запуском этой команды необходимо преобразовать оба значения из мегабайт в байты. Получается 524288000 и 5242880, соответственно (1МВ = 1048576 байт). Эти значения можно использовать в следующей команде:

Использование журнала изменений NTFS Change Journal позволяет повысить эффективность работы с файловой системой NTFS.

Управляет журналом изменений номеров последовательных обновлений (USN). Журнал изменений USN обеспечивает постоянный журнал всех изменений, внесенных в файлы на томе. По мере добавления, удаления и изменения файлов, каталогов и других объектов NTFS система NTFS вводит записи в журнал изменений USN, по одному для каждого тома на компьютере. В каждой записи указывается тип изменения и измененный объект. Новые записи добавляются в конец потока.

Синтаксис

Параметры

Параметр Описание
креатежаурнал Создает журнал изменений USN.
m = <maxsize> Указывает максимальный размер (в байтах), выделяемый файловой системой NTFS для журнала изменений.
a = <allocationdelta> Задает размер (в байтах) выделения памяти, который добавляется в конец и удаляется из начала журнала изменений.
<volumepath> Указывает букву диска (с последующим двоеточием).
делетежаурнал Удаляет или отключает активный журнал изменений USN.

Remarks

Программы могут обратиться к журналу изменений USN, чтобы определить все изменения, внесенные в набор файлов. Журнал изменений USN гораздо эффективнее, чем проверка меток времени или регистрация для получения уведомлений о файлах. журнал изменений USN включается и используется службой индексирования, службой репликации файлов (FRS), службами удаленной установки (RIS) и удаленными служба хранилища.

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

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

Журнал изменений может увеличиться до суммы значений MAXSIZE и аллокатионделта перед усечением.

Удаление или отключение активного журнала изменений занимает много времени, поскольку система должна получить доступ ко всем записям в главной таблице файлов (MFT) и установить последний атрибут USN равным 0 (нулю). Этот процесс может занять несколько минут, и он может продолжать работу после перезагрузки системы, если требуется перезагрузка. В ходе этого процесса журнал изменений не считается активным или отключен. При отключении журнала система недоступна, и все операции с журналом возвращают ошибки. При отключении активного журнала следует использовать крайне осторожно, поскольку он неблагоприятно влияет на другие приложения, использующие журнал.

Примеры

Чтобы создать журнал изменений USN на диске C, введите:

Чтобы удалить активный журнал изменений USN на диске C, введите:

Чтобы включить отслеживание диапазона с заданным размером фрагмента и порогом размера файла, введите:

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

В файловых системах NTFS и ReFS есть журнал изменений, который называется USN. Как только какой-то файл изменился, в журнал пишется информация об этом. Эту информацию можно из журнала извлечь. Журнал не бесконечный, количество записей в нём ограничено. Поэтому для какого-то конкретного файла записи в журнале может и не оказаться, например, если эта запись уже оказалась затёрта более новыми записями. Если файлов на локальном томе много и они постоянно изменяются, то записи в журнале будут жить не очень долго.

Поддерживается ли журналирование

Итак, допустим, есть произвольный файл. Стоит задача залезть в журнал изменений USN и вынуть оттуда информацию о последних производившихся с файлом операциях. Файл должен располагаться на файловой системе NTFS или ReFS. Эти файловые системы являются журналируемыми. Сначала в Windows только NTFS поддерживала журналирование. Но теперь таких файловых систем две. Вдруг в будущем появятся новые файловые системы с журналом USN? Поэтому, для определения того, есть ли вообще журнал USN или его нет на локальном томе, будем не сравнивать имена файловых систем, а будем смотреть флаги возможностей файловой системы. Какой бы она ни была, старой или новой, флаг покажет нам, поддерживает ли данная файловая система журнал USN или нет. Делается это так:

После этого вызова смотрим имя файловой системы в lpFileSystemNameBuffer, а также флаги её возможностей в dwFsFlags. Конкретно наличие журналирования проверяется так:

Выяснение версии журнала USN

Версия журнала USN 3.0 поддерживается в файловой системе ReFS. Эта файловая система на сегодняшний день присутствует только в операционной системе Windows 2012 Server. Поэтому, чтобы запрашивать данные версии 3.0, нужно прежде выяснить, что программа выполняется под управлением именно этой операционной системы, или более новой.

Подготавливаем два параметра, pReadUSN и uReadUSNSize, для последующего использования с вызовом FSCTL_READ_FILE_USN_DATA. Либо pReadUSN указывает на буфер с типом READ_FILE_USN_DATA, либо он указывает на NULL.

Получение номера USN-записи по хэндлу файла

Чтобы извлечь данные из USN-журнала о файле, нужно иметь номера записи об этом файле. Получить его можно с помощью вызова FSCTL_READ_FILE_USN_DATA. Номер извлекается из структуры, которая имеет две разные версии, которые имеют разный размер, это нужно учитывать. Чтобы учесть это, из начала структуры USN_RECORD нужно прочитать её версию, и только потом обрабатывать данные из неё.

4 Кб это достаточный размер для сохранения USN-информации об одном файле. Даже 1 Кб будет достаточно.

Теперь в uUsnNumber у нас есть номер USN-записи. Предполагаем, что она верна, хотя это может быть не так. Это может быть номер записи, которая уже затёрта в журнале другими записями. Под этим номером уже может скрываться запись совершенно о другом файле. Или это может быть номер записи в предыдущем журнале USN, который удаляли и пересоздали. Поэтому, после получения информации из журнала USN, нужно проверить, действительно ли информация оттуда относится к нашему файлу. Делается это сравнением идентификаторов файла. Идентификатор файла нужно предварительно получить (как это сделать, описано здесь).

Также, следующие запросы будут к хэндлу тома, а не файла. Нужно получить хэндл тома (hVolume), на котором расположен файл.

Получаем идентификатор USN-журнала

urd - структура READ_USN_JOURNAL_DATA может быть версии 0 или версии 1. Но отличаются они только двумя дополнительными элементами в конце структуры в версии 1. Поэтому буфер для обоих структур у нас один и тот же, а отличаться будет только размер структуры, который мы передаём в вызове (urd_size). Эти два дополнительных элемента инициализируем как 2 и 3, то есть вызов DeviceIoControl потом нам может вернуть информацию об USN либо версии 2.0, либо 3.0.

Делаем вызов FSCTL_QUERY_USN_JOURNAL, чтобы получить идентификатор текущего USN журнала тома, для того, чтобы потом сделать ещё один, последний вызов, с этим параметром. В итоге, в переменную urd типа READ_USN_JOURNAL_DATA пишется ранее полученный USN-номер записи журнала, и полученный на этом этапе идентификатор журнала.

Получаем запись из журнала USN

Теперь, когда сформирована структура READ_USN_JOURNAL_DATA, можно сделать последний вызов, который извлечёт информацию из журнала. Делает это вызов FSCTL_READ_USN_JOURNAL.

В общем, в результате вызова, оба наших указателя urv2, и urv3 указывают на буфер, где располагается то ли структура USN_RECORD_V2, то ли USN_RECORD_V3. Нужно прочитать поле MajorVersion (по любому указателю), и затем, соответственно, использовать один из двух указателей соответствующей версии для получения информации об USN-записи.

Сравнение идентификаторов из USN v2.0

Но ещё нужно проверить, правильную ли запись мы получили, относится ли она к нашему файлу, а не к другому. Нужно сравнить идентификаторы. Этот код отличается в версии 2.0 и 3.0, так как размер идентификаторов разный. В версии USN 2.0 сравнение выглядит так:

См. код функции GetFileId() тут.

Сравнение идентификаторов из USN v3.0

В версии USN 3.0 сравнение выглядит так:

См. код функции GetFileIdEx() тут.

Значение полей записей из журнала USN

В MSDN описана структура USN_RECORD. Там и смотрите описание полей структуры. Самые интересные поля это Reason и SourceInfo. Они позволяют узнать, какие именно действия привели к созданию записи в журнале USN. То есть позволяют выяснить, а что, собственно, изменилось в файле?

Казалось бы, самый первый вызов FSCTL_READ_FILE_USN_DATA и так возвращает структуру USN_RECORD, зачем остальные вызовы? А затем, что при вызове FSCTL_READ_FILE_USN_DATA в полученной таким образом структуре USN_RECORD поля Reason и SourceInfo всегда равны 0. Об этом даже в MSDN написано. Вот поэтому, одиночный вызов FSCTL_READ_FILE_USN_DATA не имеет никакого смысла. Он ничего полезного не сообщает о файле, кроме номера записи USN. Ведь все остальные поля структуры, кроме Reason и SourceInfo можно получить и более традиционными способами.

CHKDSK используется для проверки дисков и вывода отчетов о результатах проверки. Формат командной строки:

CHKDSK [том:[[путь]имя_файла]] [/F] [/V] [/R] [/X] [/I] [/C] [/L[:размер]]

Том Определяет точку подключения, имя тома или букву проверяемого диска с двоеточием.

имя_файла Файлы, проверяемые на наличие фрагментации (только FAT/FAT32).

/F Исправление ошибок на диске.

/R Поиск поврежденных секторов и восстановление их содержимого. (требует ключ /F ).

/L:размер Только для NTFS: изменение размера файла журнала до указанной величины (в КБ). Если размер не указан, выводится текущее значение размера.

/X При необходимости, принудительное отключение тома. Все открытые дескрипторы для этого тома будут недействительны. (требует параметр /F ).

/I Только для NTFS: менее строгая проверка индексных элементов.

/C Только для NTFS: пропуск проверки циклов внутри структуры папок.

Ключи /I или /C уменьшают время выполнения CHKDSK за счет пропуска некоторых проверок тома.

Тип файловой системы: NTFS.

Метка тома: DISK_C.

ВНИМАНИЕ! Параметр F не указан.

CHKDSK выполняется в режиме только чтения.

Проверка файлов (этап 1 из 3).
Проверка файлов завершена.
Проверка индексов (этап 2 из 3).
Проверка индексов завершена.
Проверка дескрипторов безопасности (этап 3 из 3).
Проверка дескрипторов безопасности завершена.
CHKDSK проверяет журнал USN..
Завершена проверка журнала USN

488384000 КБ всего на диске.
482155688 КБ в 332072 файлах.
108552 КБ в 14989 индексах.
0 КБ в поврежденных секторах.
1120884 КБ используется системой.
65536 КБ занято под файл журнала.
4998876 КБ свободно на диске.

Размер кластера: 4096 байт.
Всего кластеров на диске: 122096000.
1249719 кластеров на диске.

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

Работа программы CHKDSK делится на три основных прохода, в течение которых CHKDSK проверяет все метаданные на томе, и дополнительный четвертый проход. Термин "метаданные" означает "данных о данных." Метаданные являются надстройкой над файловой системой, в которой отслеживаются сведения обо всех файлах, хранящихся на томе. В метаданных содержатся сведения о кластерах, составляющих объем данных конкретного файла, о том, какие кластеры свободны, о кластерах, содержащих поврежденные сектора и т.д. С другой стороны, данные, содержащиеся в файле, обозначаются как "данные пользователя". В NTFS метаданные защищаются с помощью журнала транзакций. Процесс изменения метаданных делится на определенные логические этапы, или транзакции, которые фиксируются в журнале. Если последовательность действий по изменению метаданных логически не завершена, то выполняется откат по данным журнала транзакций на тот момент, когда это изменение еще не было начато. Другими словами, использование журнала транзакций, значительно повышает вероятность целостности метаданных.

Для защиты данных пользователей ( не метаданных ) в файловой системе NTFS этот способ не используется.

Этап 1. Проверка файлов

Этап 2. Проверка индексов

Этап 3. Проверка дескрипторов безопасности

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

Этап 4. Проверка секторов

Данный этап выполнения CHKDSK определяется наличием параметра /R при запуске программы. Выполняется поиск поврежденных секторов в свободном пространстве тома . CHKDSK выполняет попытку чтения каждого сектора на томе, и , при обнаружении ошибки, кластер, в который входит данный сектор, помечается как дефектный и исключается из логической структуры тома. Даже без использования ключа /R программа всегда проверяет чтением секторы, относящиеся к таблице MFT ( к метаданным ). Кроме того, секторы, которые используются для области пользовательских данных, проверяются на предыдущих этапах работы CHKDSK.

Необходимо учитывать тот факт, что время выполнения CHKDSK с ключом /R может быть значительным. Кроме того, современные жесткие диски имеют встроенную систему самотестирования и контроля параметров (S.M.A.R.T) , наличие которой делает бессмысленным использование режима поиска поврежденных секторов с помощью CHKDSK , поскольку все современные накопители постоянно выполняют внутренние подпрограммы контроля технического состояния и самодиагностики, а также встроенные на микропрограммном уровне процедуры переназначения плохо читающихся секторов ( нестабильных секторов ) на секторы из резервной области ( процедура remap или ремап ). Данные процессы происходят невидимо для пользователя компьютера. Поэтому, наличие сбойных блоков ( Bad Blocks ) возможно только при отсутствии свободного места в резервной области для переназначения, или при возникновении сбоев в момент записи данных в сектор, например, при аварийном выключении первичного электропитания.


Usn Journal verification completed — запись, которая может быть отображена в отчете проверке диска утилитой CHKDSK.

Запись означает проверка журнала USN завершена.

Перевод надписи на русский:


Следующие строки за надписью могут быть примерно такими:

CHKDSK is verifying file data (stage 4 of 5)…
File data verification completed.
CHKDSK is verifying free space (stage 5 of 5)…
Free space verification completed.

После надписи компьютер может зависнуть — что делать дальше?

Возможно некоторые советы смогут вам помочь:

  1. Можно попробовать в диспетчере устройство удалить все IDE ATA/ATAPI, после выполнить перезагрузку.
  2. Также дело может быть в кабеле жесткого диска (шлейф). Один юзер написал — после замены кабеля проблема исчезла.
  3. Зависание может быть, если некоторые дескрипторы безопасности не используются, однако при это остались в системе. Данные дескрипторы отвечают за разрешение доступа к файлам. Файлы могли быть удалены, а дескрипторы остались — команда CHKDSK может пытаться их удалить, но не всегда получается. Возможно из-за этого и происходит зависание на этапе USN Journal verification completed.
  4. Возможно команда CHKDSK проверяет журнал USN Journal только при условии что он активен в файловой системе NTFS.

По поводу журнала

Один пользователь связывался с Майкрософт. Ему ответили — журнал USN Journal ни в коем случае нельзя удалять. Он появляется обычно после удаления большого количества файлов.

На заметку. Журнал USN — внутренний журнал файловой системы NTFS, которой содержит записи об изменении файлов на диске.

Дополнительные советы

Если при запуске Windows автоматом запускается команда chkdsk — это означает на диске/в файловой системе присутствуют ошибки. Они могут быть вызваны как программами причинами, так и аппаратными:

  • Программные — ошибки файловой системы, например после внезапного отключения электричества.
  • Аппаратные — глючат шлейфы, коннекторы, разьемы на материнской плате или жестком диске.

Можно попробовать разобрать ПК, почистить от пыли жесткие диски, попробовать их подключить к другим портам. Либо отключить все. И проверять по одному.

На одном форуме найден совет — если все таки получится запустить Windows, тогда вручную проверьте проблемный диск командой chkdsk с такими аргументами:

Для вызова командной строки зажмите Win + R, далее напишите cmd. Чтобы открыть справку по команде, введите chkdsk /?

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

Запись при проверке в Windows XP:


Запись, предположительно в Windows 7:


Заключение

Мы выяснили, USN Journal verification completed — не ошибка, а запись в журнале выполнения проверки диска. Запись свидетельствует об успешной проверки журнала USN.

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Целостность файлов на жёстком диске является важной компонентной стабильно работающей компьютерной системы. Появление в файлах и файловой структуре различных ошибок, нарушение логической структуры диска, возникновение на диске битых секторов приводит к некорректной работе ПК, сбоям в работе системы, глюкам и зависаниям. Для профилактики подобных проблем в операционной системе, начиная с архаичной MS DOS и заканчивая современными версиями ОС Windows 10, предусмотрен специальный инструмент, призванный проверять и восстанавливать целостность файловой системы, бороться с логическими и физическими ошибками на диске. Речь идёт о системной утилите CHKDSK, и в данном материале я расскажу, что это за утилита, для чего она предназначена, и как может помочь команда CHKDSK /F /R для устранения повреждений файловой системы на вашем ПК.


Используйте CHKDSK /F /R для устранения повреждений файловой системы

Что такое CHKDSK?

CHKDSK (сокращение от английского «check disk» — проверка диска) – это системный инструмент, предназначенный для проверки жёсткого диска на наличие логических ошибок, битых секторов (bad sector), а также исправления найденных им проблем.

Функционал CHKDSK позволяет восстанавливать логическую структуру диска, включая исправление некорректных точек входа MFT (главной файловой таблицы). В случае нахождения битых секторов, выступающих в двух основных формах – «мягкой» (появляются, когда данные были записаны некорректно) и «жёсткой» (битые сектора возникли из-за физического повреждения диска), CHKDKS обычно восстанавливает «мягкие» битые сектора, и маркирует «жёсткие» таким образом, чтобы они не могли быть далее использованы системой.

Работа данной утилиты может занять довольно продолжительное время, причём для своей работы CHKDSK требует обязательного наличия эксклюзивных прав на запись диска. Потому, если вы, находясь в ОС Виндовс, захотите проверить системный диск (обычно С) с помощью данного инструмента, то система предложит вам перезагрузить компьютер, и, при последующем старте, CHKDSK получит расширенные права, а затем проведёт проверку вашего диска на наличие ошибок.

Функционал команды CHKDSK

Существуют две основные формы активации данной утилиты, позволяющие вам запустить chkdsk:

    Активация стандартным способом. Жмём на «Мой компьютер», выбираем нужный диск для проверки, наводим на него курсор, и кликаем правую клавишу мыши. В появившемся меню выбираем «Свойства», переходим на вкладку «Сервис» и жмём на «Выполнить проверку» вверху.


Нажмите на «Выполнить проверку» для доступа к функционалу CHKDSK


Установите требуемые галочки и нажмите на «Ок»

  • Если диск не системный, тогда проверка будет проведена незамедлительно, если же диск системный – тогда компьютер внесёт в своё расписание проверку данного диска, и при последующей перезагрузке ваш диск будет проверен функционалом CHKDSK;
  • Активация с помощью командной строки. Запустите командную строку от имени администратора, в ней введите:

CHKDSK (имя тома) /(флаг)

Например, часто используемой формой активации CHKDKS является команда:

CHKDSK C: /F /R

где С: — имя тома, /F и /R — используемые флаги.

Приведённая мной команда запускает CHKDSK, предписывая последнему выполнить проверку диска С на наличие повреждённых секторов, и восстановить имеющиеся на них данные (флаг /F обязывает CHKDSK исправлять ошибки на диске, флаг /R обязывает CHDSK искать на диске повреждённые сектора, и попытаться восстановить данные на них).


Команда CHKDSK /F /R применяется для проверки и исправления ошибок на диске

Другие флаги (команды) CHKDSK таковы:

  • /V – во время проверки файловой системы FAT/FAT32 показывает путь к файлам на диске и их имена;
  • /X – предварительное отключение тома (требуется обязательное задействование флага /F);
  • /I – отключает тщательную проверку индексов. Используется только в файловой системе NTFS, позволяет ускорить проверку диска;
  • /C — отключает проверку циклов внутри папок. Используется только в NTFS, также позволяет ускорить проверку;
  • /L:(размер в килобайтах) – изменение размера файла журнала до указанной величины (только NTFS);
  • /B – повторная проверка повреждённых кластеров диска (только NTFS, требует обязательного наличия ключа /R)

Если же вы просто введёте в командной строке команду «CHKDSK» (без кавычек), то утилита «CHKDSK /F /R для устранения повреждений файловой системы» просканирует ваш диск на наличие ошибок в режиме «просто чтение» (read only), никак не исправляя их.

Заключение

В файловых системах NTFS и ReFS есть журнал изменений, который называется USN. Как только какой-то файл изменился, в журнал пишется информация об этом. Эту информацию можно из журнала извлечь. Журнал не бесконечный, количество записей в нём ограничено. Поэтому для какого-то конкретного файла записи в журнале может и не оказаться, например, если эта запись уже оказалась затёрта более новыми записями. Если файлов на локальном томе много и они постоянно изменяются, то записи в журнале будут жить не очень долго.

Поддерживается ли журналирование

Итак, допустим, есть произвольный файл. Стоит задача залезть в журнал изменений USN и вынуть оттуда информацию о последних производившихся с файлом операциях. Файл должен располагаться на файловой системе NTFS или ReFS. Эти файловые системы являются журналируемыми. Сначала в Windows только NTFS поддерживала журналирование. Но теперь таких файловых систем две. Вдруг в будущем появятся новые файловые системы с журналом USN? Поэтому, для определения того, есть ли вообще журнал USN или его нет на локальном томе, будем не сравнивать имена файловых систем, а будем смотреть флаги возможностей файловой системы. Какой бы она ни была, старой или новой, флаг покажет нам, поддерживает ли данная файловая система журнал USN или нет. Делается это так:

После этого вызова смотрим имя файловой системы в lpFileSystemNameBuffer, а также флаги её возможностей в dwFsFlags. Конкретно наличие журналирования проверяется так:

Выяснение версии журнала USN

Версия журнала USN 3.0 поддерживается в файловой системе ReFS. Эта файловая система на сегодняшний день присутствует только в операционной системе Windows 2012 Server. Поэтому, чтобы запрашивать данные версии 3.0, нужно прежде выяснить, что программа выполняется под управлением именно этой операционной системы, или более новой.

Подготавливаем два параметра, pReadUSN и uReadUSNSize, для последующего использования с вызовом FSCTL_READ_FILE_USN_DATA. Либо pReadUSN указывает на буфер с типом READ_FILE_USN_DATA, либо он указывает на NULL.

Получение номера USN-записи по хэндлу файла

Чтобы извлечь данные из USN-журнала о файле, нужно иметь номера записи об этом файле. Получить его можно с помощью вызова FSCTL_READ_FILE_USN_DATA. Номер извлекается из структуры, которая имеет две разные версии, которые имеют разный размер, это нужно учитывать. Чтобы учесть это, из начала структуры USN_RECORD нужно прочитать её версию, и только потом обрабатывать данные из неё.

4 Кб это достаточный размер для сохранения USN-информации об одном файле. Даже 1 Кб будет достаточно.

Теперь в uUsnNumber у нас есть номер USN-записи. Предполагаем, что она верна, хотя это может быть не так. Это может быть номер записи, которая уже затёрта в журнале другими записями. Под этим номером уже может скрываться запись совершенно о другом файле. Или это может быть номер записи в предыдущем журнале USN, который удаляли и пересоздали. Поэтому, после получения информации из журнала USN, нужно проверить, действительно ли информация оттуда относится к нашему файлу. Делается это сравнением идентификаторов файла. Идентификатор файла нужно предварительно получить (как это сделать, описано здесь).

Также, следующие запросы будут к хэндлу тома, а не файла. Нужно получить хэндл тома (hVolume), на котором расположен файл.

Получаем идентификатор USN-журнала

urd - структура READ_USN_JOURNAL_DATA может быть версии 0 или версии 1. Но отличаются они только двумя дополнительными элементами в конце структуры в версии 1. Поэтому буфер для обоих структур у нас один и тот же, а отличаться будет только размер структуры, который мы передаём в вызове (urd_size). Эти два дополнительных элемента инициализируем как 2 и 3, то есть вызов DeviceIoControl потом нам может вернуть информацию об USN либо версии 2.0, либо 3.0.

Делаем вызов FSCTL_QUERY_USN_JOURNAL, чтобы получить идентификатор текущего USN журнала тома, для того, чтобы потом сделать ещё один, последний вызов, с этим параметром. В итоге, в переменную urd типа READ_USN_JOURNAL_DATA пишется ранее полученный USN-номер записи журнала, и полученный на этом этапе идентификатор журнала.

Получаем запись из журнала USN

Теперь, когда сформирована структура READ_USN_JOURNAL_DATA, можно сделать последний вызов, который извлечёт информацию из журнала. Делает это вызов FSCTL_READ_USN_JOURNAL.

В общем, в результате вызова, оба наших указателя urv2, и urv3 указывают на буфер, где располагается то ли структура USN_RECORD_V2, то ли USN_RECORD_V3. Нужно прочитать поле MajorVersion (по любому указателю), и затем, соответственно, использовать один из двух указателей соответствующей версии для получения информации об USN-записи.

Сравнение идентификаторов из USN v2.0

Но ещё нужно проверить, правильную ли запись мы получили, относится ли она к нашему файлу, а не к другому. Нужно сравнить идентификаторы. Этот код отличается в версии 2.0 и 3.0, так как размер идентификаторов разный. В версии USN 2.0 сравнение выглядит так:

См. код функции GetFileId() тут.

Сравнение идентификаторов из USN v3.0

В версии USN 3.0 сравнение выглядит так:

См. код функции GetFileIdEx() тут.

Значение полей записей из журнала USN

В MSDN описана структура USN_RECORD. Там и смотрите описание полей структуры. Самые интересные поля это Reason и SourceInfo. Они позволяют узнать, какие именно действия привели к созданию записи в журнале USN. То есть позволяют выяснить, а что, собственно, изменилось в файле?

Казалось бы, самый первый вызов FSCTL_READ_FILE_USN_DATA и так возвращает структуру USN_RECORD, зачем остальные вызовы? А затем, что при вызове FSCTL_READ_FILE_USN_DATA в полученной таким образом структуре USN_RECORD поля Reason и SourceInfo всегда равны 0. Об этом даже в MSDN написано. Вот поэтому, одиночный вызов FSCTL_READ_FILE_USN_DATA не имеет никакого смысла. Он ничего полезного не сообщает о файле, кроме номера записи USN. Ведь все остальные поля структуры, кроме Reason и SourceInfo можно получить и более традиционными способами.

Читайте также: