NTFS журнал USN_REASON_HARD_LINK_CHANGE событий

Question

Я написал программу, которая считывает индекс NTFS и журнал, похожий на то, что описано здесь: http://ejrh.wordpress.com/2012/07/06/using-the-ntfs-journal-for-backups/
и она работает достаточно хорошо.
В дополнение к обычным журнала событий USN_REASON_CLOSE, USN_REASON_FILE_CREATE, USN_REASON_FILE_DELETE и т.д.»Я получаю событие с разумом USN_REASON_HARD_LINK_CHANGE. Я хотел бы иметь возможность обновлять индекс каталога в соответствии с этим событием, но я не могу найти никакой информации об этом. only documentation is:

NTFS файловая система жесткая ссылка добавляется или удаляется из файла или каталога . Жесткая ссылка файловой системы NTFS, похожая на ссылку POSIX hard , является одной из нескольких записей в каталоге, которые видят один и тот же файл или каталог .

Что это значит? где была создана жесткая ссылка? или он был удален? как получить дополнительную информацию о том, что произошло?

Answer 1

Как и в случае с USN, я ожидаю, что вам нужно пройти немного проб и ошибок, чтобы заставить его работать правильно. Эти наблюдения/догадки могут, я надеюсь, быть полезными:

Когда последняя жесткая ссылка на файл удалена, файл удаляется; поэтому, если последняя жесткая ссылка была удалена, вы должны увидеть USN_REASON_FILE_DELETE вместо USN_REASON_HARD_LINK_CHANGE. Я считаю, что каждый ссылочный номер ссылается на файл (или каталог, но NTFS не поддерживает несколько жестких ссылок на каталоги AFAIK), а не на жесткую ссылку. Поэтому сразу после записи события, по крайней мере, номер ссылки на файл должен быть действительным и указывать на другое имя файла.

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

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

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

Предполагаете, вы уже искали близлежащие записи изменений, которые могут содержать дополнительную информацию? Например, нет записи USN_REASON_RENAME_NEW_NAME, созданной при создании жесткой ссылки, или USN_REASON_RENAME_OLD_NAME при удалении жесткой ссылки? Или парные записи USN_REASON_HARD_LINK_CHANGE, один для файла, один для каталога, содержащего жесткую ссылку на файл, связанный с файлом? (Желательного мышления, я ожидаю, но было бы не больно смотреть!)

Для целей тестирования вы можете создавать жесткие ссылки с помощью команды mklink.

Answer 2

Я знаю, что это древний, но я наткнулся на это, исследуя связанную проблему. Вот что я нашел: жесткие ссылки являются усложняющим фактором при чтении USN. Вы можете получить записи журнала, описывающие изменение, на один номер ссылки на файл посредством изменений, сделанных с помощью любой жесткой ссылки, которая была создана. Как правило, и исходный вопрос, жесткие ссылки являются альтернативными ссылками на каталог, через которые можно получить доступ к одному файлу. Таким образом, все характеристики файла разделяются для каждой ссылки (за исключением имен и исходных номеров родительских файлов). Технически вы не можете указать, какая запись является оригиналом и какая ссылка.

Существует тонкое различие, которое проявляется, если вы запрашиваете таблицу основных файлов (используя DeviceIOControl и Fsctl_Enum_Usn_Data). Запрос возвращает только один репрезентативный файл независимо от того, сколько ссылок существует. Вы можете запрашивать ссылки с помощью NtQueryInformationFile, запрашивая FILE_HARD_LINK_INFORMATION. Я думаю о записи, возвращаемой запросом MFT в качестве основной записи, а возвращаемые элементы NtQueryInformationFile в качестве ссылок ... однако основная запись может быть удалена, и одна из ссылок будет повышена ... так что это всего лишь домашнее хозяйство мысли и еще немного.

Обратите внимание, что возникает проблема, когда одна из жестких ссылок перемещается или переименовывается. В этом случае записи журнала для переименования или перемещения отражают имя файла и ссылочный номер родительского файла затронутой ссылки. Проблема возникает, если вы запрашиваете только сводные записи «on-close». В таком случае вы никогда не увидите запись USN_REASON_RENAME_OLD_NAME ... потому что эта запись USN никогда не ассоциируется с ассоциированным REASON_CLOSE. Без этой лаконичности вы не сможете легко определить, какое имя или местоположение ссылки было изменено. Вы должны прочитать usn с ReadOnlyOnClose, установленным в 0 в Read_Usn_Journal_Data_V0. Это гораздо более частый запрос, но без него нельзя точно связать изменение с одной ссылкой или другой.