Здравствуйте, x64, Вы писали:
AB>>В примере scanner уже есть связка драйвера и приложения, куда просто добавить предупреждающее сообщение.
x64>Насчёт "просто добавить" это ты погорячился. Для задачи автора, в сканере довольно много лишнего функционала получается.
Всегда можно найти к чему придраться в чужом ответе.
Естественно, лишнее необходимо удалять.
Задача — написать драйвер, который бы при попытке открытия файла выводил предупреждающее сообщение. Как я понял, лучше это организовать с помощью MiniFilter.
Собственно вопрос. Какой из сорцов WDK лучше взять за основу? (я смотрел в сторону miniSpy) И т.к. я пишу первый драйвер, то что еще можно посмотреть/учесть по теме?
N>Задача — написать драйвер, который бы при попытке открытия файла выводил предупреждающее сообщение. Как я понял, лучше это организовать с помощью MiniFilter.
Можно фильтр, можно минифильтр, как угодно. Если ранее с файловыми фильтрами дел не имел, то лучше мини, конечно. Брать готовый пример и наворачивать функционал я бы не советовал, потому как у тебя собственно функционала слишком мало, и если ты начинёшь что-то выкидывать из сэмплов, — дров наломаешь порядком. Пиши с нуля. Подглядывая в документацию и сэмплы. Основные направления разработки — фильтрация Create-запроса плюс посылка уведомления об этом в твоё UM-приложение. Для этого реализовать очередь запросов придётся, см. faq
Здравствуйте, x64, Вы писали:
N>>Задача — написать драйвер, который бы при попытке открытия файла выводил предупреждающее сообщение. Как я понял, лучше это организовать с помощью MiniFilter.
x64>Можно фильтр, можно минифильтр, как угодно. Если ранее с файловыми фильтрами дел не имел, то лучше мини, конечно. Брать готовый пример и наворачивать функционал я бы не советовал, потому как у тебя собственно функционала слишком мало, и если ты начинёшь что-то выкидывать из сэмплов, — дров наломаешь порядком. Пиши с нуля. Подглядывая в документацию и сэмплы. Основные направления разработки — фильтрация Create-запроса плюс посылка уведомления об этом в твоё UM-приложение. Для этого реализовать очередь запросов придётся, см. faq
Если не критичто открытие файла операционной системой я посоветую предупреждение не вешать на Открытие, по тому что эта операция хоть и может быть задеражана и отложенна но как-бы не штатный это режим. Я бы лучше все это зделал на попытке любого доступа, так мы перформанс оставим на уровне и многие приложения не буду уходить в ступор, почему? потому что доступ хоть и не весь, предпологает асинхронность и многие разработчики об этом думают, а вот открытие всегда синхронная операция и как правило ее задержка приведет к ступору приложения.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
СР>Если не критичто открытие файла операционной системой я посоветую предупреждение не вешать на Открытие, по тому что эта операция хоть и может быть задеражана и отложенна но как-бы не штатный это режим. Я бы лучше все это зделал на попытке любого доступа, так мы перформанс оставим на уровне и многие приложения не буду уходить в ступор, почему? потому что доступ хоть и не весь, предпологает асинхронность и многие разработчики об этом думают, а вот открытие всегда синхронная операция и как правило ее задержка приведет к ступору приложения.
Не вижу проблемы в ступоре приложения. А с производительностью можно накосячить где угодно. И да, мой опыт подсказывает, что твоё беспокойство излишне.
Здравствуйте, x64, Вы писали:
СР>>Если не критичто открытие файла операционной системой я посоветую предупреждение не вешать на Открытие, по тому что эта операция хоть и может быть задеражана и отложенна но как-бы не штатный это режим. Я бы лучше все это зделал на попытке любого доступа, так мы перформанс оставим на уровне и многие приложения не буду уходить в ступор, почему? потому что доступ хоть и не весь, предпологает асинхронность и многие разработчики об этом думают, а вот открытие всегда синхронная операция и как правило ее задержка приведет к ступору приложения.
x64>Не вижу проблемы в ступоре приложения. А с производительностью можно накосячить где угодно. И да, мой опыт подсказывает, что твоё беспокойство излишне.
А мне кажется что если в итоге к этому файлу полезут через сеть проблему возникнут и это уже не просто что пересовка приложения не будет происходить а хуже.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, x64, Вы писали:
СР>>А мне кажется что если в итоге к этому файлу полезут через сеть...
x64>Если из ядра полезут — тоже проблемы могут быть (srv.sys ведь в ядре работает, не так ли?). Это отдельно вопрос решать надо.
Давайте все что выше по стеку лежит преплетем. — еще раз повторю если есть возможность все надо делать по доступу а не во время открытия.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
Здравствуйте, x64, Вы писали:
СР>>...если есть возможность все надо делать по доступу а не во время открытия.
x64>Приводи конкретный пример почему именно так. Пока неубедительно.
я все описал, а доводы что нам начхать на все, бывает и хуже и в других местах считаю плохими.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
— еще раз повторю если есть возможность все надо делать по доступу а не во время открытия.
