Коллеги, я не так давно написал и опубликовал программу "Убийца нежелательных окон 1С".

Адрес проекта на гитхабе: https://github.com/milkin-vl/KillerOfUnwantedWindows1C

Суть проблемы, которую она решает: пользователь может, не работая в ФАЙЛОВОЙ базе, заблокировать её так, чтобы стали невозможны тестирование, обновление, архивация и другие операции, требующие монопольного доступа. И что самое важное: такого пользователя никак не выгнать стандартными средствами платформы. Подробнее читайте в описании по ссылке.

Судя по отзывам, которые я получил от пользователей, программа со своими задачами справляется. Поэтому решил опубликовать её, ещё и здесь, возможно кто-то найдёт её полезной и для себя тоже.

В целом - зачет. Пиши еще.

Но эти окна - это не единственная и не самая большая беда файловых баз. Файловая база - это геморрой во всех проявлениях. В особенности при конкурентной работе.

"пользователь может, не работая в ФАЙЛОВОЙ базе, заблокировать её" // Что имеешь в виду под "работать"?

(2) классика - пользователь сначала запустил 1С, а потом пошел мусор выносить и больше его не видели.

(2) да, речь о пользователях, которые застряли на этапе авторизации и/или загрузке базы в том или ином виде.

Хз-хз. Мне под "не работать в инфобазе" сразу на ум приходит отсутствие клиентского сеанса и связанного с ним процесса ОС.
Так если это возникает только при запуске 1С, то почему бы не перефразировать "пользователь может, запуская базу, заблокировать..."?

А что за "загрузка базы" в третьем пунктике?

(5) согласен полностью, внесу изменения в описание проекта

(6) речь об этом абзаце?

"Пользователь запустил загрузку базы и ушел, не дождавшись её окончания. Но конфигурация не загрузилась, так как появилось окно о том, что конфигурация отличается от конфигурации базы данных. Пока будет висеть эта загрузка, базу монопольно не заблокировать."

(7) Также твой сценарий с оставлением базы, убиением сеанса и появлением окошка аутентификации можно выразить фразой не "пользователь может", а "инфобаза может оставаться заблокированной". Пользователь же не совершает каких-то действий, чтобы это произошло - это просходит само собой.

(0) каким образом убийство происходит? от шары отключаются?

(8) Да. При загрузке dt вроде не может возникать сообщений о несоответствии основной конфигурации от конфигурации БД...

(11) Что-то я не понял, причём тут загрузка dt?

(12) Так Я и спрашиваю в (6)

Видимо речь об открытии инфобазы

(10) закрывается окно авторизации средствами WinApi или завершается процесс, в зависимости от ситуации.

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

(13) да, конечно, речь об открытии базы :)

(15) те нужно на конечном компе запускать?

Блин, я даже не думал, что текст (которые я несколько раз выверял) может вызывать столько разночтений.

(10)
var p = Process.GetProcessById(Id);
//...
p.Kill();

(17) https://github.com/milkin-vl/KillerOfUnwantedWindows1C#Принцип-работы

(19) да, но это если только сама загрузка базы (открытие) зависла по тем или иным причинам. Иначе просто программно закрываем окно авторизации 1С.

Всё верно ставить надо на клиентские компьютеры.

Если же у вас работа в терминальном сервере - то только на него.

А если файловая база через веб-сервер раздается, то веб-клиент никогда и никак не может блокировать ее? Или в этом случае Обновлятор просто гасит сам веб-сервер?

Еще получется, что с настройками по умолчанию если пользователь открыл инфобазу, появилось окно авторизации, он 119 секунд ничего в нем не делает, а потом решил-таки ввести пароль, то на 120-135 секунде у него это окошко безусловно закроется? )

(23) окна 1с, открытые в веб-браузере, не попадают под действие программы

но там описанная проблема не так актуальна, так как между файловой базой и пользователями всегда есть веб-сервер, который мы всегда можем выключить программно

по поводу поведения обновлятора: прошу вас задать этот вопрос в его ветке, чтобы не уводить эту ветку в сторону

(24) да, согласно настройкам по умолчанию закроется

(24) я не определяю активность пользователя в конкретном окне, а определяю общую активность (чтобы перехватить момент, когда пользователь открыл окно авторизации и ушёл)

а в описанном вами случае: программа не увидит разницы между:
- пользователь на 120 секунде начал работать в окне
- или пользователь продолжил на 120 секунде активничать в другой программе, а окно авторизации по прежнему болтается где-то в фоне (пользователь забыл про него)

Но почему бы вместо убивания клиентских процессов ОС просто не обрубрать права на каталог с инфобазой?

(28) это уже зверства какие-то...))

не каждая программа для администрирования или архивации предусматривает такие возможности

а установив "киллер 1с" можно будет вполне положиться на штатные возможности платформы в части выдворения пользователей (после создания блокировки сеансов)

(28) а ещё я не уверен, что Windows (не проверял) даст возможность изменить права к папке и файлам, один из которых открыт монопольно в другой программе

но даже если это можно - имхо не очень корректный способ

А что происходит после убиения клиентского процесса? Он перестает удерживать служебный файлик в каталоге инфобазы?

(31) да, перестаёт

(30) Так получается, что для инфобазы вообще нет разницы, убивается клиентский процесс или у этого процесса (пользователя ОС) просто отбирается право на каталог инфобазы, разве нет?

(33) вероятно разницы не будет

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

(0) на fpc можно было бы и без нетов всяких вражеских реализовать.. кода 5 строчек)))

(0) я думал речь о "всплывающих сообщениях" 1С, обрадовался сначала


напишите кто-нить WinAPI-киллер, мой не работает больше :(

(0) Весело тут у вас.

Но ничего, это до первой убитой базы.

(35) По поводу 5 строчек для проекта в целом я бы поспорил... :)

А в целом можно рассматривать этот проект как прототип (который я сделал очень быстро на привычном мне .net, я там больше всего времени с msi провозился).

И вот если этот прототип выстрелит (и его начнут действительно использовать многие), тогда, конечно, уже будет иметь смысл переписать его хоть на паскале, хоть на c++. В мире такая практика для успешных программ на .net есть.

А сейчас переписывать, чтобы только сэкономить немного оперативной памяти... процессорное время мы не сэкономим, так там вся тяжёлая логика - это как раз вызов функций winapi.

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

Автор, я так понимаю, тупо делает terminatethread()/terminateprocess() не заморачиваясь закрытием файлов.

(38) вы точно описание работы внимательно прочитали? напишите возможный сценарий, при котором вмешательство программы может убить базу.

(39) На дельфях напиши, там и размер маленький и библиотеки таскать не нужно.

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

Насколько помню убивать не обязательно, просто послать окну сообщение типа WM_Close.

(42) KillAction=CloseProcess

Если есть открытый файл, данные которого кэшированы и не попали на диск, они и не попадут на него.

(45) и вы тоже не читали описания? :)

(46) так база закрывается только при зависании на этапе авторизации/загрузки базы, то есть пользователь ещё не зашёл в базу и ничего там сделать заведомо не успел.

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

Но, повторюсь, если программой будут пользоваться, конечно, перепишем на чём нибудь более нативном.

(0) Долго делал?

(50) на саму программу я потратил максимум пару дней, там кода совсем немного

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

а затем я ещё 2 дня копался с msi - вот, что оказалось самым сложным в этом проекте, так как раньше я с созданием такого типа установщика не работал

ну и в целом это мой первый опыт публикации программы под свободной лицензией на гитхабе, поэтому ещё время ушло на вникание в нюансы и оформительство

(48) Понятно. Вот сейчас глянул, до окна авторизации в базу действительно ничего не пишется, скорее всего базу не уронить.
Пишется в ЖР и в словарь полнотекстового поиска, если уроните, то только их.

DuplicateHandle() c DUPLICATE_CLOSE_SOURCE
flushfilebuffers()
CloseHandle()

и CreateRemoteThread() вам в помощь, но это долго и муторно.

(52) спасибо за пояснения

по идее программа не делает ничего такого, чего бы не сделал админ, обнаруживший, что у пользователя:
- висит окно авторизации в базу (он бы просто закрыл это окно, то же делает и программа)
- более 10 минут висит загрузка базы (он бы просто снял процесс из диспетчера задач, то же делает и программа)