-
-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Поведение при большом количестве записей в hosts #231
Comments
Приветствую!
Для управления большим числом хостов служит инструмент Hosts File Manager, однако именно с огромным числом (к примеру > 1k) хостов он не тестировался. Интересно, как себя поведёт. Интеграции с игнор-листом там конечно нет, но вполне можно добавить.
это сделано как раз потому что:
также, у списка результатов есть свой лимит; и на прошлой версии интерфейса (v2) это вызывало значительные подвисания программы, надо взглянуть как сейчас обстоят дела
да, это пожалуй разумная идея, в списке результатов уже есть похожий по назначению пункт:
можно сделать, чтобы при добавлении его в игнор-лист, добавлялся не сам этот пункт, а все текущие записи в hosts.
Делать подобное ради экономии на реестре не вижу смысла, т.к. реестр по своей архитектуре является базой данных, которая как раз и предназначена для хранения большого числа записей с максимальной скоростью доступа к ним. Hosts с примерно 10к записей (пусть по ~ 40 символов на каждую) должен увеличить общий объем реестра на не более чем 1 MiB. Это вообще ни о чем. На счёт собственно портативной версии, она пока в проекте, в низком приоритете. Однако, в плане переносимости игнор-листа, он специально зашифрован и не может быть перенесён на другой ПК простым экспортом/импортом. Так было сделано ради защиты от вредоносов, которые таким же способом обходят сканер HiJackThis. Тем не менее, после ваших слов я сейчас подумываю, что можно реализовать иначе и тратить время на шифрование вообще не понадобится. В окне сканирования можно добавить предупреждение, чтобы было явно видно, что игнор-лист не пуст, а при проверке из-под AutoLogger там в любом случае применяется ключ для отключения обработки игнор-листа. При этом в меню программы как вариант, можно добавить удобный пункт "Импорт/Экспорт настроек". Подумаем над этим.
Это уже есть. |
Тут скорее не об экономии места речь, а о выделении конкретных данных в отдельную запись. Скорость обращения к реестру фактически такая же, как и скорость обращения к файлу, ничем не отличается. Только хранение/перенос осложняются. PS: о Hosts File Manager не знаю, у меня три других редактора hosts. (а, наверное понял - речь о встроенном в HJT редакторе) |
Если речь о простом не-индексированном списке, то нет. Когда файл с записями не фиксированной длины, то для изменения одного элемента требуется перезаписать весь файл, с чтением аналогично - чтобы прочитать одну запись, требуется ее поиск. Не хочу усложнять утилиту. Когда появится портативная версия, то в ней и будут все настройки (не только hosts) в отдельном файле. А пока можно ограничится простым импортом/экспортом. Простой батник с
справится с задачей. Конечно, в текущий момент игнор-лист перенесется в поврежденном виде. Посоветовавшись, решили, что шифрование можно убрать, так что в новых версиях, такой перенос настроек можно будет выполнить без проблем.
Речь не в том, есть шифрование или нет, а в том, что в данный момент оно залочено под конкретную машину. Если перенести игнор-лист на другую машину, то ключ не совпадёт и список там расшифруется неправильно. P.S. Еще раз, обращу внимание, что реестр от такого увеличения в размерах не станет работать медленнее. Там все реализовано на хешировании и указателях. Вот если часто перезаписывать данные, то происходит эффект фрагментации. Но это не как с диском, скорость все равно не падает, по той же причине - это база данных. От фрагментации будет страдать размер реестра. Но и это решаемо, например, с помощью вспомогательной утилиты defrag, которая распространяется с ABR, используемой внутри HJT. В комплекте HJT ее нет (вырезана), но можно скачать с сайта автора: http://dsrt.dyndns.org:8888/files/abr.zip |
Я 30+ лет с компами, живу с ними, необязательно расписывать всё :) Реестр если и дефрагментировал когда, то Registry Workshop. Мощнейшая штука, если не знаком - рекомендую всячески. |
Привычка, расписывать подробно. Тогда меньше недосказанности и предположений.
хорошо :) |
Попробовал. Даже скрытые ключи показывает*, правда не все. А вот поиск очень быстрый и результат списком, что очень удобно. Спасибо, что посоветовали. |
А ПКМ да управление правами доступа, разве не помогает? |
Там не в правах дело. Разработчик либо не знает, либо не стал заморачиваться, либо не захотел предоставлять такую возможность всем подряд (что собственно и правильно сделал :)) И это не так легко реализуется. Вообщем, ушли в оффтоп... |
При превышении некоторого количества записей хостов в System32\drivers\etc\hosts после каждого сканирования, даже начального, показывается лишь мизерная часть хостов.
Каждый новый перезапуск, если в прошлый раз добавили все видимые хосты в исключения, появляется снова новая порция хостов. При огромном числе хостов в hosts процедуру добавления в игнор можно растянуть на почти бесконечное время.
Соответственно каждый добавляемый игнор увеличивает количество данных, записанных в реестр
Вероятно следовало бы показывать все найденные изменения, а не порционно по 40 строк за раз.
Однако в случае огромного числа записей это будет абсолютным трешем, соответственно лучше всего добавить некую функцию по добавлению всех имеющихся записей хостов в список игнорирования разом (допустим, пользователь уверен в текущем своём hosts и хочет просто добавить всё в игнор и следить только за изменениями с текущего момента) - может кнопку "добавить все хосты в игнор", может вопрос при сканировании при обнаружении большого числа записей (необязательно если сканирование впервые, хосты можно массово прописать после первого использования hijackthis - на просторах есть утилиты, добавляющие массово опасные хосты в hosts)
Вероятно в таком случае разумнее всего список игнора как и настройки хранить в отдельном файле нежели в реестре - что-то вроде "портабельной" версии, в том же %AppData%. Так и переносимость будет проще в случае краха/поломки/переустановки системы (за много лет не сталкивался, но в последнее время много экспериментов творю на живой системе, и увалил несколько раз за полгода... ищу так сказать "золотую середину" - и каждый раз ставил всё с нуля, и самое худшее при переносе данных - возня с реестром, поиск зависимостей, какая программа в какой/каких ветках складывает свои данные + ещё нередко встречается и в реестре и в файлах...). Импорт старых настроек из реестра предыдущих версий сходу не прошёл - оказалось, что в текущей версии путь записей в реестре отличается от каких-то прошлых - раньше было в TrendMicro\HiJackThisFork (и всегда создавалась пустая ветка TrendMicro\HiJackThis), а теперь просто в корне HiJackThis+...
Соответственно, если будет добавлена возможность хранения в .ini в %AppData%, то при выборе такого варианта переносить настройки из реестра в .ini, если они хранились в реестре.
Ну и для тех, у кого есть записи в старой ветке TrendMicro\HiJackThis при запуске переносить эти данные в новую ветку, если новой ветки нет, а если есть, то считать что уже настроено в новой ветке, и старую просто удалять как хвост от прошлых версий.
The text was updated successfully, but these errors were encountered: