По умолчанию службы Windows запускаются в каталоге sytem32 (обычно C:\WINDOWS\system32).
Есть ли способ создать другой рабочий каталог? Я думаю о параметре реестра ниже HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SomeService.
Итак - можно ли это сделать?
Вы можете использовать DLL-инъекцию для вызова SetCurrentDirectory после того, как процесс уже запущен. Для этого вам потребуется создать приложение-инжектор, а также DLL для инъекции. Существуют некоторые учебные пособия; наверное, два лучших из них, которые я нашел:
Чтобы пройти через это, вам потребуется приличный опыт программирования на C ++ (и рабочая среда сборки).
Однако это предполагает, что служба просматривает текущий каталог. Другая возможность состоит в том, что он использует %path%. Вы говорите, что это "начинается с system32, пробует еще несколько местоположений и, в конечном итоге, свой собственный каталог ", так что мне это кажется более вероятным.
Сравните каталоги, которые вы видите в procmon с вашим %path%. Если они одинаковы, рассмотрите возможность изменения SYSTEM %path% или %path% пользователя, запустившего службу, так что каталог, в котором вы хотите выполнить поиск, был первым.
Однако я считаю, что Фред прав - вы вряд ли увидите какое-либо существенное улучшение производительности, если сделаете что-либо из этого, если только это не произойдет. очень часто. Простые операции открытия файла не особенно дороги, особенно если это локальный путь, а файл на самом деле не существует.
Сделайте это в основной функции службы:
GetModuleFilename. Он получит имя файла модуля (exe), включая путь, в форме C:\path\to\exe\your_service.exe.std::string функция find_last_of()), чтобы найти последнюю обратную косую черту. Удалите / обрежьте строку оттуда, чтобы получить путь к вашему модулю и, следовательно, каталог вашего exe.SetCurrentDirectory и вуаля!Добавьте строковое значение «AppDirectory» к ключу параметров и установите значение для желаемого рабочего каталога.
Как и MattB, я не знаю способа изменить рабочий каталог службы без доступа к исходному коду. Для этого конкретного сценария вполне вероятно, что дополнительные проверки каталогов не налагают столько ненужной дисковой активности по сравнению с объемом операций ввода-вывода, необходимого для операции полнотекстового индексирования. Даже если вы могли бы их оптимизировать, полный текстовый индекс будет занимать много места на диске по природе зверя.