Как найти файл в ntfs

Управление свободным и занятым дисковым пространством

В системе Windows учет свободных и занятых дисковых блоков ведется при помощи битового вектора (bit map или bit vector), например, 00111100111100011000001, где каждый блок представлен одним битом, принимающим значение 0 или 1, в зависимости от того, занят он или свободен. В файловой системе NTFS битовый массив сам является файлом. Его атрибуты и дисковые адреса хранятся в 6-й записи таблицы MFT.

Реализация директорий

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

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

Для больших каталогов совокупность записей о файлах не помещается в MFT—запись каталога. Она является нерезидентным атрибутом и организована в виде B+ дерева, обеспечивающего быстрый поиск имени файла в алфавитном порядке. MFT—запись каталога содержит корень этого дерева, а его ветви размещаются в отдельных блоках диска.

Поиск файла по имени

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

При поиске файла вначале при помощи механизма символьных ссылок в пространстве имен объектов решается задача трансляции имени диска «в стиле DOS» или буквы диска во внутренние имена устройств Windows. Для этого библиотечный вызов, содержащий имя файла в качестве параметра, передается библиотеке kernel32.dll и перед именем помещается название каталога именованных ресурсов «??» в пространстве имен менеджера объектов. В результате «F:tmpMyFile.txt» преобразуется в «??F:tmpMyFile.txt». Далее в каталоге ?? ищется символьное имя «F:», которое является ссылкой на объект-раздел жесткого диска, например, «DeviceHarddiskVolume5». Далее находится таблица MFT этого раздела, затем осуществляется навигация по каталогам и отыскивается искомый файл, см.
рис.
12.5.

Для поиска файлов в каталоге применяются функции FindFirstFile и FindNextFile (см. MSDN).

Прогон программы, осуществляющей поиск файла в каталоге

Приведенная программа выводит список файлов в каталоге с заданным шаблоном поиска. Информация о найденных файлах содержится в структуре WIN32_FIND_DATA, которая является одним из параметров функций FindFirstFile и FindNextFile. Входным параметром функции FindFirstFile служит шаблон поиска, а выходным — дескриптор поиска, который является входным параметром функции FindNextFile и хранит информацию о текущем состоянии поиска (аналог указателя текущей позиции). Для закрытия описателя в данном случае применяется функция FindClose (а не CloseHandle как обычно).

Точки повторного анализа. Монтирование дисков. Образование ссылок

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

Монтирование файловых систем

Операция монтирования файловой системы, хранящейся на разделе диска, обеспечивает ей связь с уже существующей иерархией файловых систем и делает ее файлы доступными для процессов. Техника монтирования описана в предыдущей лекции. Монтирование базовых дисков осуществляется автоматически при первом обращении к диску. Это делает диспетчер монтирования (Mountmgr.sys). Сведения о монтированных дисках имеются в реестре в разделе HKLMSYSTEMMountedDevices.

Создание точек монтирования (mount points) — связывание каталога NTFS реализовано с помощью точек повторного анализа. Программы, осуществляющие навигацию по каталогам, должны, обнаружив точку повторного анализа (в данном случае точку монтирования), прибегнуть к помощи кода, направляющего процесс дальнейшей навигацию на новый том. Программы, предоставляющие информацию о суммарном количестве файлов на диске или в каталоге, также должны учитывать наличие точек монтирования.

Точки монтирования в системе можно найти при помощи Win32-функций FindFirstVolumeMountPoint и FindNextVolumeMountPoint.

Создание связей

Связывание файлов — техника, заимствованная из Unix, — образование для файла или каталога нескольких родительских каталогов, см.
рис.
12.6.

Соединение между директорией и разделяемым файлом называется «связью» или «ссылкой» (link). Дерево файловой системы превращается в циклический граф.

ОС Windows (как и Unix) поддерживает два вида связей — жесткие (hard link) и символические (symbolic link). В случае жесткой связи запись о файле появляется в новом каталоге, а MFT-запись этого файла включает счетчик количества ссылок на данный файл. Удаление файла приводит к уменьшению счетчика на 1, и реальное удаление и освобождение его блоков происходит, когда значение счетчика равно 0.

Символическая линковка — создание нового файла, который содержит путь к связываемому файлу. Обычно в системе создается каталог, который связывается с уже существующим каталогом. Этот метод удобен для «подъема» (уменьшения степени вложенности) каталогов. Удаление символической связи на связываемый файл никак не влияет. Удаление связываемого файла делает символическую связь недействительной.

Жесткие связи создаются вызовом Win32-функции CreateHardLink. Штатной утилиты, поддерживающей жесткие связи, нет, хотя в состав ресурсов Windows для этих целей включена POSIX утилита ln.

Символическую связь (иногда говорят точку соединения, junction) можно образовать при помощи входящей в состав ресурсов Windows утилиты linkd.exe или при помощи свободно распространяемой утилиты junction.exe с сайта http://www.sysinternals.com.

Тот факт, что операции монтирования и связывания могут превратить иерархическое дерево файловой системы в циклический граф, делает работу с ней более сложной. Поскольку теперь к файлу существует несколько путей, программа поиска файла может найти его на диске несколько раз. Простейшее практическое решение данной проблемы — ограничить число директорий при поиске. С этой целью при поиске файлов Windows Explorer останавливает рекурсию по достижении 32-го уровня вложенности или при превышении длины пути в 256 символов. Это зависит от того, какое событие наступит раньше..

Полное устранение циклов при поиске — довольно трудоемкая процедура, выполняемая специальными утилитами и связанная с многократной трассировкой директорий файловой системы.

Образование циклического графа можно проиллюстрировать на примере
[
Руссинович
]
образования рекурсивной точки монтирования.

Написание, компиляция и прогон программы, определяющей, помечен ли указанный каталог в качестве точки повторного анализа

Создайте пустой каталог и сделайте его точкой монтирования или символической связью. При помощи функции GetFileAttributes установите у данного каталога наличие флага FILE_ATTRIBUTE_REPARSE_POINT.

Совместный доступ к файлу

Пользователи часто нуждаются в разделении файлов и совместном доступе к ним.

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

Очевидно, что потоки должны синхронизировать доступ к совместно используемым файлам или каталогам, чтобы получить предсказуемый результат. Между двумя операциями read одного потока другой поток может модифицировать данные, что для многих приложений неприемлемо. ОС Windows предлагает стандартное решение данной проблемы на уровне пользователя — предоставить возможность одному из потоков захватить часть файла между двумя записями для монопольного доступа. Для этого используются Win32-функции LockFile и UnlockFile.

Время на прочтение
2 мин

Количество просмотров 134K

Если в Windows XP поиск файлов был хоть и медленным, но все-таки работоспособным, то в Windows 7 он превратился во что-то совсем непонятное. Многие успешно пользуются поиском в Far’е или Total Commander’е вместо стандартных средств Windows. Когда на дисках очень много файлов, такой поиск также выполняется медленно. Я бы вряд ли поверил, если бы не попробовал сам, что файлы можно находить мгновенно (!), прямо во время ввода имени файла в строку поиска. Заинтересовались?

Чудо-программа, которая сэкономила мне массу времени и продолжает выручать каждый день, называется Everything. Это бесплатное мини-приложение (размер portable-версии — 272 КБ) делает всего одну простую вещь — оно ищет файлы на дисках по части имени файла. Магия в том, что поиск происходит мгновенно, по мере ввода букв имени файла в строку поиска (как при «живом поиске» Google). Это открывает гораздо бОльшие возможности поиска файлов. Например, если вы забыли точное название файла, вы можете быстро попробовать ввести разные варианты названия. При «классическом» поиске вам пришлось бы каждый раз раз долго ждать завершения поиска, а здесь сразу видно, нашлось что-то или нет:

Как это работает?

Программа при первом запуске сканирует таблицу распределения файлов (NTFS MFT) и сохраняет результат сканирования в небольшой кэш-файл. Сканирование дисков производится очень быстро — даже при нескольких терабайтах данных сканирование займет не более одной минуты. На основе полного списка файлов на всех дисках Everything строит в памяти структуру данных для быстрого поиска. При последующих запусках повторное сканирование всех дисков происходить уже не будет: программа будет брать информацию из кэш-файла и лишь обновлять ее. Для отслеживания изменений файлов программа использует информацию из USN-журнала раздела NTFS.

Ограничения программы:

• Программа осуществляет поиск только по NTFS-разделам.
• Поиск производится только по именам файлов (по атрибутам, датам и содержимому файлов поиск невозможен).

Я уверен, Everything станет вашим надежным помощником и сэкономит многие и многие часы. А для Microsoft это повод к размышлению над тем, как на самом деле должен работать поиск

Поиск данных файла

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

На
что влияет этот параметр:
на скорость навигации по файлу (доступ
к произвольному фрагменту файла). Любая
работа с большими файлами данных и
документов, если их размер — несколько
мегабайт и более. Этот параметр показывает,
насколько сильно сама
файловая система 
страдает от фрагментации файлов.

• ntfs
  способна обеспечить быстрый поиск
  фрагментов, поскольку вся информация
  хранится в нескольких очень компактных
  записях (типичный размер — несколько
  килобайт). Если файл очень сильно
  фрагментирован (содержит большое число
  фрагментов) — ntfs придется использовать
  много записей, что часто заставит
  хранить их в разных местах. Лишние
  движения головок при поиске этих данных,
  в таком случае, приведут к сильному
  замедлению процесса поиска данных о
  местоположении файла.

• FAT32,
  из-за большой области самой таблицы
  размещения будет испытывать огромные
  трудности, если фрагменты файла
  разбросаны по всему диску. Дело в том,
  что FAT (File Allocation Table, таблица размещения
  файлов) представляет собой мини-образ
  диска, куда включен каждый его кластер.
  Для доступа к фрагменту файла в системе
  FAT16 и FAT32 приходится обращаться к
  соответствующей частичке FAT. Если файл,
  к примеру, расположен в трех фрагментах
  — в начале диска, в середине, и в конце
  — то в системе FAT нам придется обратиться
  к фрагменту FAT также в его начале, в
  середине и в конце. В системе FAT16, где
  максимальный размер области FAT составляет
  128 Кбайт, это не составит проблемы — вся
  область FAT просто хранится в памяти,
  или же считывается с диска целиком за
  один проход и буферизируется. FAT32 же,
  напротив, имеет типичный размер области
  FAT порядка сотен килобайт, а на больших
  дисках — даже несколько мегабайт. Если
  файл расположен в разных частях диска
  — это вынуждает систему совершать
  движения головок винчестера столько
  раз, сколько групп фрагментов в разных
  областях имеет файл, а это очень и очень
  сильно замедляет процесс поиска
  фрагментов файла.

Вывод:
Абсолютный лидер — FAT16, он никогда не
заставит систему делать лишние дисковые
операции для данной цели. Затем идет
ntfs — эта система также не требует чтения
лишней информации, по крайней мере, до
того момента, пока файл имеет разумное
число фрагментов. FAT32 испытывает огромные
трудности, вплоть до чтения лишних сотен
килобайт из области FAT, если файл разбросан
по разным областям диска. Работа с
внушительными по размеру файлами на
FAT32 в любом случае сопряжена с огромными
трудностями — понять, в каком месте на
диске расположен тот или иной фрагмент
файла, можно лишь изучив всю
последовательность кластеров файла с
самого начала, обрабатывая за один раз
один кластер (через каждые 4 Кбайт файла
в типичной системе). Стоит отметить, что
если файл фрагментирован, но лежит
компактной кучей фрагментов — FAT32 всё
же не испытывает больших трудностей,
так как физический доступ к области FAT
будет также компактен и буферизован.

Соседние файлы в предмете Защита информации

• #
• #
• #
• #

  10.12.2013203.78 Кб23Как заставить работать Windows XP быстрее.doc

• #
• #

  10.12.20136.07 Mб26Масштабирование.doc

• #
• #

Хорошая статья, но все же неполная — пропущено начало. Главный вопрос, как ось доходит до всего этого. Вот в FAT’е, например, она обращается в бут-сектор, где есть вся информация о носителе, откуда она узнает, где какие области начинаются. А ЗДЕСЬ КАК????

Вот, знаю только то, что ОС обращается в загрузошный кластер, где находится номер начального кластера файла MFT… А потом? Как она доходит до $. — простым последовательным просмотром записей???? Скажем так, мне понятна логика, но не физика

З.Ы. хотя не исключаю, что сам ничего не понял в этой статье, т.к. не читал ее от начала до конца, а только пункт про папки