Быстрый поиск набора имен файлов на томах NTFS, в идеале через его MFT

Я сейчас пишу инструмент, который находит потерянные файлы библиотеки iTunes как для Mac, так и для Windows. На Mac я могу быстро находить файлы, называя их с помощью замечательной функции «Поиск по каталогам».

Однако в Windows, похоже, нет OS API для поиска по имени файла (или есть?).

После некоторого поиска в Google я узнал, что существуют инструменты (такие как TFind, Everything), которые напрямую читают каталог NTFS и сканируют его, чтобы найти файлы по имени.

Я хотел бы сделать то же самое, но без необходимости начинать с нуля (хотя в прошлом я написал довольно много дисковых инструментов, у меня никогда не было сил копаться в NTFS).

Интересно, есть ли готовые библиотеки, возможно, в виде .dll, которые дадут мне эту функцию поиска: передать имя файла, вернуть его путь.

А как насчет службы индексирования Windows? По крайней мере, когда я пробовал это на недавно установленной системе XP Home, операция Поиск в меню Пуск фактически сканировала все каталоги, что говорит о том, что у нее нет полной базы данных. Поскольку я вообще не являюсь пользователем Windows, мне интересно, почему это не работает.

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


person Thomas Tempelmann    schedule 17.11.2010    source источник
comment
Windows Search работает быстро, только если вы ищете проиндексированные местоположения.   -  person MSalters    schedule 22.11.2010
comment
Думаю, вы имеете в виду следующее: msdn .microsoft.com / en-us / library / bb266517 (v = VS.85) .aspx? ppud = 4 - выглядит сложно. Я посмотрю на него поближе, спасибо.   -  person Thomas Tempelmann    schedule 22.11.2010
comment
Не делайте этого, пожалуйста, пожалуйста. Послушайте парня, который говорит вам использовать журнал USN   -  person Ana Betts    schedule 22.11.2010
comment
Хорошо. Вы меня уговорили. Вы бы даже убедили меня, если бы сказали, почему поиск Windows - не такая уж хорошая идея. Может потому, что всего не найдет? (заметьте, я автор Find Any File для OS X, на случай, если вам когда-нибудь понадобится найти все на Mac :)   -  person Thomas Tempelmann    schedule 23.11.2010


Ответы (1)


Кажется, что лучший способ решить вашу проблему - использовать Журнал изменений Windows.

Проблема: если он не включен для тома или том не является NTFS, вам нужен запасной вариант (или включите журнал изменений, если это NTFS). Вам также потребуются права администратора для доступа к Журналу изменений.

Вы получаете файлы, используя FSCTL_ENUM_USN_DATA и DeviceIOControll с LowUsn = 0. Это напрямую обращается к MFT и записывает все имена файлов в предоставленный буфер. Поскольку он последовательно обращается к MFT, он быстрее, чем API FindFirstFile.

person UrOni    schedule 22.11.2010
comment
Да, мне известно об этой опции (она также доступна в OS X по умолчанию с 10.5). Но, боюсь, это слишком сложно для понимания. - person Thomas Tempelmann; 22.11.2010
comment
И журнал изменений показывает мне только последние изменения, верно? Поэтому, если я не буду вести процесс, записывающий каждое изменение, мне все равно придется сначала выполнить полное сканирование. Правильный? Затем я возвращаюсь к своему первоначальному вопросу: как выполнить быстрое полное сканирование? - person Thomas Tempelmann; 22.11.2010
comment
Если вы установите StartUSN в ноль, как описано, это быстро даст вам все файлы на томе (и это действительно быстро). Если вы хотите изменений, вам нужно установить StartUSN на большее число. Затем вы получите файлы, измененные с момента этого USN. - person UrOni; 22.11.2010
comment
Прости. Это FSCTL_ENUM_USN_DATA, а не FSCTL_QUERY_USN_JOURNAL - плохо. - person UrOni; 22.11.2010
comment
Ах, тогда журнал на самом деле делает больше, чем просто ведение журнала, как кажется (в отличие от функции OS X, которая сообщает вам только об изменениях во время прослушивания). Спасибо за разъяснения. Тогда я займусь этим. Я использую доступные параметры, а в противном случае прибегаю к медленным процессам. - person Thomas Tempelmann; 23.11.2010
comment
Я не думаю, что вам нужно включить журнал изменений для использования FSCTL_ENUM_USN_DATA. Существует отдельный ioctl для отслеживания изменений, FSCTL_READ_USN_JOURNAL, который, вероятно, больше похож на журнал OSX, который вы использовали раньше, хотя NTFS больше похож на ленту безопасности с закрытыми субтитрами: ваш процесс не должен выполняться, когда изменение происходит до тех пор, пока вы запрашиваете журнал, прежде чем он будет завершен и перезаписан. - person Ben Voigt; 26.12.2010
comment
Бен: Это защитная лента с замкнутым контуром. Скрытые субтитры - это необязательные субтитры в телешоу. В любом случае, я полагаю, что FSCTL_ENUM_USN_DATA проходит MFT, возвращая записи USN совпадающих файлов, а FSCTL_READ_USN_JOURNAL просматривает журнал USN, возвращая совпадающие файлы (и, возможно, ожидая появления новых записей). - person Gabe; 26.12.2010
comment
@Gabe: Да, я имел в виду замкнутый контур. Это иногда случается, когда я оставляю комментарии слишком поздно ночью. - person Ben Voigt; 30.12.2010
comment
+1 за эту отличную информацию. А вот ссылка на документацию MSDN по FSCTL_ENUM_USN_DATA: msdn.microsoft.com/en-us/library/aa364563%28VS.85%29.aspx - person Helge Klein; 09.01.2011
comment
Взгляните на эти ссылки: microsoft.com/msj/0999/journal/journal .aspx и technet.microsoft.com/en-us/library /bb742450.aspx. Эта серия из двух частей под названием «Следите за своими NTFS-дисками: объяснение журнала изменений Windows 2000» помогла мне сохранить рассудок при реализации функции журнала изменений. - person Hannes de Jager; 21.02.2011