Здравствуйте, ononim, Вы писали:

O>Если не указал FILE_SHARE_READ — значит не хочешь чтобы ктото читал файл кроме тебя.

В данном случае "кроме" лишнее, поскольку SYNCHRONIZE не открывает файл ни для чтения, ни для записи. То есть, практический смысл ограничения отсутствует, и его наличие можно оправдать исключительно использованием простейшего алгоритма проверки.

O>уверен, что еслиб вместо указания разрешения надо было бы указывать запрет (типа FILE_DENY_READ) — у вас бы никаких претензий не было.

Претензия же не к способу указания запрета, а к возникновению запрета в ситуации, при которой он не имеет практического смысла.

O>Например, файл может быть не доступен для меня (для моего токена) на запись SECURITY_DESCRIPTOR'ом, но доступен для чтения. Тем не менее я могу захотеть блокировать запись в него с других акаунтов, имея права на чтение пока я его читаю чтоб не читать абы-что.

Прекрасно — указываете чтение в маске доступа, и автоматически появляется тот самый практический смысл в указании маски ShareAccess.

O>Уверены что с FILE_READ_ATTRIBUTES|SYNCHRONIZE, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE — не дает открыть?

Если добавить FILE_READ_ATTRIBUTES — скорее всего, даст открыть. Но FILE_SHARE_READ указать таки придется.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Насколько я понял, "Adding a filter driver to a WDM driver stack does not require a system restart, unless an underlying device is a system boot device". Я не работал с клавиатурными драйверами, но мне кажется, что он не есть "boot device", нет?

Так даже для non-boot устройств при использовании стандартного варианта с AddDevice придется запрашивать полную перестройку стека, а это слишком радикально, и для данного применения еще и бессмысленно. Моему фильтру все равно, в каком месте стека цепляться — главное, чтобы поверх kbdclass, а этому вполне отвечает реакция на уведомление о появлении соответствующих интерфейсов. IRP_MN_REMOVE_DEVICE я обрабатываю и отцепляюсь, так что вся динамика работает нормально.

O>>Если не указал FILE_SHARE_READ — значит не хочешь чтобы ктото читал файл кроме тебя.
ЕМ>В данном случае "кроме" лишнее, поскольку SYNCHRONIZE не открывает файл ни для чтения, ни для записи. То есть, практический смысл ограничения отсутствует, и его наличие можно оправдать исключительно использованием простейшего алгоритма проверки.
Это у вас отсутствует. Я уже указал причину — вот я не хочу открывать файл ни на чтение ни на запись а заблокировать чтение запись хочу. Вот функционал у моей программы такой — блокировать файл чтоб лругие не могли к нему доступицца и все на этом. Сходу это может понадобицца для синхронизации доступа к файлам по сети. Создаем в каталоге файл lock.dat, открываем его на чтение позволяя file_share_read — имеем multiple-readers access. Затем, если хотим залочить весь каталог — открываем его на synchronize без каких либо access флагов — имеем multiple-writers access, открываем его на запись, не позволяя никакого share — имеем single read-write access к каталогу.

O>>уверен, что еслиб вместо указания разрешения надо было бы указывать запрет (типа FILE_DENY_READ) — у вас бы никаких претензий не было.
ЕМ>Претензия же не к способу указания запрета, а к возникновению запрета в ситуации, при которой он не имеет практического смысла.
Вы не экстрасенс и не архитект ядра ОС чтобы точно знать, что имеет практический смысл, а что нет. Опять же — правильный API должен быть формализуем минимальным количеством фраз. Лишняя заметка в Remarks — большой минус в карму разработчика API. Функционал ядра должен быть туп как пробка — сказали открыть файл — значит надо открыть файл, сказали не давать никому открывать файл — значит не давать никому открывать файл. Все, никаких проверок на здравый смысл, цвет кожи и национальность девелопера не должно быть — это дело более высокоуровневых API. Вон во внуково Ту204 развалился по причине сложно-формализуемой логики управления. Пилот включил реверс — а реверс не включился, потому что одно колесо не на земле. "Зачем вам реверс, если колеса не на земле?" правильно? А пилот не в курсе был таких заморочек (которые появились тока в новой модификации ТУ204), замешкался, допустил другие ошибки пока втыкал в это чудо и в результате самолет частями выехал на дорогу. А ну и до кучи, чтоб совсем весело была, та самая недоформализованная логика вместо включения реверса ему вывела двигатель на 90% тягу. Все просто — полный реверс == полная тяга + реверс. Реверс — низзя, потому что не имеет практического смысла, пока колеса не на земле, тяга — можно — смысл имеет и на земле и в воздухе. Вот и получили максимум тяги вместо максимума реверса. Систему явно программисты проектировали.

O>>Например, файл может быть не доступен для меня (для моего токена) на запись SECURITY_DESCRIPTOR'ом, но доступен для чтения. Тем не менее я могу захотеть блокировать запись в него с других акаунтов, имея права на чтение пока я его читаю чтоб не читать абы-что.
O>>Уверены что с FILE_READ_ATTRIBUTES|SYNCHRONIZE, FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE — не дает открыть?
ЕМ>Прекрасно — указываете чтение в маске доступа, и автоматически появляется тот самый практический смысл в указании маски ShareAccess.
ЕМ>Если добавить FILE_READ_ATTRIBUTES — скорее всего, даст открыть. Но FILE_SHARE_READ указать таки придется.
Ситуация — я хочу открыть файл на FILE_READ_ATTRIBUTES, прочитать его аттрибуты и быть уверенным что никто их не поменяет пока он открыт мной (включая last access time). Открываю его на FILE_READ_ATTRIBUTES и вуаля.
С большего кстати если взглянуть со стороны — открытие файла тока с SYNCHRONIZE доступом не имеет особо практического смысла. Однако ведь — вам понадобилось.

Здравствуйте, ononim, Вы писали:

O>Функционал ядра должен быть туп как пробка

Если бы виндовый функционал действительно был таким — я не стал бы удивляться данному примеру. Но, коли он во многих случаях проявляет излишний интеллект — мог бы проявлять и здесь.

Кстати, каким образом эта "тупая логика" объясняет, что FILE_READ_ACCESS с FILE_SHARE_READ вызывает Sharing Violation, а SYNCHRONIZE с FILE_SHARE_READ — не вызывает? Каким образом файл должен быть открыт, чтобы последующие открывания работали именно так?

O>Вон во внуково Ту204 развалился по причине сложно-формализуемой логики управления.

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

O>пилот не в курсе был таких заморочек (которые появились тока в новой модификации ТУ204)

Если что, пилот обязан быть в курсе всех этих "заморочек" — это его работа, он по ней регулярно сдает экзамены и проходит тесты. И пилотов, кстати, было двое, плюс бортинженер, и все они "были не в курсе".

O> Реверс — низзя, потому что не имеет практического смысла, пока колеса не на земле, тяга — можно — смысл имеет и на земле и в воздухе. Вот и получили максимум тяги вместо максимума реверса. Систему явно программисты проектировали.

Там все совсем не так (управление оборотами в Ту-204 механическое). Почитайте здесь и здесь.

O>С большего кстати если взглянуть со стороны — открытие файла тока с SYNCHRONIZE доступом не имеет особо практического смысла. Однако ведь — вам понадобилось.

А что делать, если "тупой как пробка" интерфейс ядра использует функционал работы с файлами для определения адреса объекта устройства по имени? Он там глубоко избыточен. А открывание файла без чтения и записи может быть полезно, например, просто с целью создания живой ссылки — для удержания файла от удаления, или устройство — от демонтирования.

P.S. Блин, как же достала эта дебильная связка билайна с корбиной и RSDN...

Здравствуйте, Евгений Музыченко,

ГМ>>Насколько я понял, "Adding a filter driver to a WDM driver stack does not require a system restart, unless an underlying device is a system boot device". Я не работал с клавиатурными драйверами, но мне кажется, что он не есть "boot device", нет?

ЕМ>Так даже для non-boot устройств при использовании стандартного варианта с AddDevice придется запрашивать полную перестройку стека, а это слишком радикально, и для данного применения еще и бессмысленно.
--
Да, правильно, надо запрашивать полную перестановку стека. В чем проблема это сделать?

С уважением,
Геннадий Майко.

Здравствуйте, x64,

ГМ>>Насколько я понял, "Adding a filter driver to a WDM driver stack does not require a system restart, unless an underlying device is a system boot device". Я не работал с клавиатурными драйверами, но мне кажется, что он не есть "boot device", нет?

x64>Судя по всему, ему для отладочных целей детачмться нужно по запросу, а с аттачем-то проблем нет, конечно.
--
Возможно.
Я бы в этом случае написал маленькую утилитку, которая бы устанавливала, пере-устанавливала и снимала драйвер-фильтр, что-то типа специализированного devcon.

С уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Да, правильно, надо запрашивать полную перестановку стека. В чем проблема это сделать?

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

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Я бы в этом случае написал маленькую утилитку, которая бы устанавливала, пере-устанавливала и снимала драйвер-фильтр

Инсталлятор-деинсталлятор у него и так есть. Проблема именно с динамическим перезапуском.

Здравствуйте, Евгений Музыченко,

ГМ>>Да, правильно, надо запрашивать полную перестановку стека. В чем проблема это сделать?

ЕМ>В том, что для консольной клавиатуры это невозможно. Ну и вообще, Вы действительно считаете полную перестройку стека наиболее подходящим способом присоединения к стеку дополнительного фильтра?
--
Ну, я ж не даром спрашивал, является ли консольная клавиатура "boot device". Если не является, то я предложил Вам метод, который, насколько я знаю, является "официальным".

И да, я не вижу проблем в установке/переустановке/удалении драйвера фильтра путем перестройки стека драйверов.

С уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>И да, я не вижу проблем в установке/переустановке/удалении драйвера фильтра путем перестройки стека драйверов.

Это когда устройство никому не нужно. Все клавиатурные устройства, например, постоянно открыты CSRSS, и закрывать их он не собирается. Каким образом можно перестроить стек, не затрагивая клиентов устройства?

Здравствуйте, Евгений Музыченко,

ГМ>>И да, я не вижу проблем в установке/переустановке/удалении драйвера фильтра путем перестройки стека драйверов.

ЕМ>Это когда устройство никому не нужно. Все клавиатурные устройства, например, постоянно открыты CSRSS, и закрывать их он не собирается. Каким образом можно перестроить стек, не затрагивая клиентов устройства?
--
Наверное, PNP-manager как-то это разрулит, если его правильно попросить.

Я вот взял сейчас и воткнул в мой комп еще одну USB-клавиатуру. И после установки драйвера получил новое устройство с драйвером-фильтром и, соответственно, могу теперь работать с двумя клавиатурами. А когда ее отключил от разъема USB, то драйвер успешно выгрузился. А могу, не отключая клавиатуру, сделать драйверу uninstall — и драйвер из системы выгрузился. А теперь сделал "scan for hardware changes" — и драйвер появился в системе.
Вот до (или после) uninstall добавьте информацию о драйвере-фильтре в систему, и после "scan for hardware changes" он появится в стеке клавиатуры.

С уважением,
Геннадий Майко.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Кстати, каким образом эта "тупая логика" объясняет, что FILE_READ_ACCESS с FILE_SHARE_READ вызывает Sharing Violation, а SYNCHRONIZE с FILE_SHARE_READ — не вызывает? Каким образом файл должен быть открыт, чтобы последующие открывания работали именно так?

Был открыт с FILE_READ_ACCESS, 0

Здравствуйте, Геннадий Майко, Вы писали:

ЕМ>>Каким образом можно перестроить стек, не затрагивая клиентов устройства?

ГМ>Наверное, PNP-manager как-то это разрулит, если его правильно попросить.

Не, я запамятовал, что для PnP-устройств это штатная ситуация — там же без согласия клиентов отменяются все IRP и деактивируется FDO.

ГМ>могу, не отключая клавиатуру, сделать драйверу uninstall — и драйвер из системы выгрузился. А теперь сделал "scan for hardware changes" — и драйвер появился в системе.

Вот меня смущает, что там нет Disable, а есть только Uninstall. То есть, вместо перестроения стека имеем полный цикл удаления и установки драйвера.

ГМ>Вот до (или после) uninstall добавьте информацию о драйвере-фильтре в систему, и после "scan for hardware changes" он появится в стеке клавиатуры.

Для конкретно этого драйвера так не получится — консольная-то клавиатура не перезапускается.

Здравствуйте, Ligen, Вы писали:

ЕМ>>Кстати, каким образом эта "тупая логика" объясняет, что FILE_READ_ACCESS с FILE_SHARE_READ вызывает Sharing Violation, а SYNCHRONIZE с FILE_SHARE_READ — не вызывает? Каким образом файл должен быть открыт, чтобы последующие открывания работали именно так?

L>Был открыт с FILE_READ_ACCESS, 0

Не сходится. Ononim уже несколько раз подчеркнул, что такая спецификация доступа якобы означает открывание в монопольном режиме, с запретом любых видов доступа для остальных.

ЕМ>>>Кстати, каким образом эта "тупая логика" объясняет, что FILE_READ_ACCESS с FILE_SHARE_READ вызывает Sharing Violation, а SYNCHRONIZE с FILE_SHARE_READ — не вызывает? Каким образом файл должен быть открыт, чтобы последующие открывания работали именно так?
L>>Был открыт с FILE_READ_ACCESS, 0
ЕМ>Не сходится. Ononim уже несколько раз подчеркнул, что такая спецификация доступа якобы означает открывание в монопольном режиме, с запретом любых видов доступа для остальных.
Где это я писал "любых"? С запретом тока чтения, записи и удаления. synchronize в эти варианты не входит — потому работает. Если конечно указать FILE_SHARE_READ, иначе чтение уже пытаетесь запретить вы.