Встала следующая проблема. Есть некоторая библиотека, осуществляющая низкоуровневую работу с файловыми системами (NTFS, FAT16, FAT32). В текущей "стабильной" ветке реализован доступ на чтение. Это подразумевает под собой : поиск файла по полному пути, работа с символьными ссылками и точками монтирования, получение списка файлов в каталоге, чтение файла и потоков данных NTFS, ... В планах реализовать также и удаление. Удаление уже практически реализовано, но есть одно но. Есть проблема синхронизации с драйвером файловой системы. Поясню в чем она заключается: * Я, работая напрямую с диском, модифицирую внутренние структуры файловой системы. * Однако эти изменения в большинстве случаев не отображаются. Драйвер файловой системы кэшируют доступ ко всем файлам, и в результате не только не видет эти изменения, но также успешно их затирает. Получается следующая ситуация. Я удаляю файл. Специальными утилитами вроде WinHEX проверяю это. Файла действительно нет. Однако ОС показывает, что файл есть и успешно с ним работает. После перезагрузки или спустя некоторое времени те же утилиты показывают, что файл снова появился. В данном случае есть одно решение - это блокировка тома. IOCTL_LOCK_VOLUME - блокирует том и сбрасывает кэш на диск. Если в мою библиотеку добавить блокировку тома перед удалением файла, то файл успешно удаляется и все вроде бы отлично. Однако есть одно но. Этот способ не подходит. Обработчик IOCTL_LOCK_VOLUME возвращает ошибку в случае, если есть открытые файлы на данно томе. Таким образом например системный том, на котором установлена Windows, заблокировать неудастся никак. Запретить ОС писать на том, в то время как я выполняю критические операции (вроде удаления), особой сложности не составляет. Однако все портит кэш. Теперь собственно вопрос. Можно ли каким либо образом заставить файловую систему или ОС принудительно сбросить кэш? Или, что вообще можно сделать в данном случае?
Эта, на unix это делается методом unmount/patch/mount или remount. Ессно во втором случае нету гарантии что реализация FS не держит что-то в cache - ведь это что-то будет сброшено на диск при unmount. Ты ж изменяешь данные под FS слоем... Единственное полное решение ты получишь только если заставишь FS сделать "sync from disk". В общем случае это remount.
Об этом я и писал. Тот же unmount/patch/mount можно сделать и в Windows. Только сомневаюсь, что у тебя получится размонтировать диск, когда на нем тысячи открытых файлов. И в Unix подозреваю та же ситуация. А вопрос в том и стоял, как заставить FS сделать "sync from disk", ну или хотябы "flush to disk".
Ну, задача дурацкая, согласись... Логически, реализации FS никогда не надо делать "sync from disk". Ну а "flush to disk", думаю, можно сделать из (мини-)фильтра. Правда тут же теряется смысл - твой код патчит диск, а вот с NTFS ты будешь разговариваешь из фильтра...
Ну понятно, что дурацкая. Только вот, что поделаешь? Если нужно реализовать удаление заблокированных файлов, то здесь другого подхода я не вижу. Есть конечно отложенное удаление, но это плохой вариант.
1) Глянь unlocker: http://ccollomb.free.fr/unlocker/ 2) поубивай процессы которые "держут" файлы 3) если всё плохо, то может это решается через фильтр?
С этим все понятно. Такие методы меня не интересуют. P.S. Как ты собираешся таким образом удалить например ntoskrnl.exe? Понятно, что моя цель не в этом, но все же...
Для разлочивания файла не надо убивать процесс. Достаточно сдублировать себе хендл и потом закрыть его. Другое дело, что с большой вероятностью процесс сам убъется от такой наглости.
