На случай, если станций таких много, есть способ автоматизировать удаление этого файла со стороны сервера.
Буду благодарен за совет...
По шагам. В процессе написания обнаружилось, что на winxp это работать пока что не будет.
1. Включить frontdoor в "Администрирование – Конфигурация сервера – Модули". При необходимости (!) изменить прослушиваемый интерфейс и порт в "Администрирование – Удалённый доступ к серверу". Перезапустить демона (из ЦУ или терминала – не важно).
2. Подключиться к frontdoor командой /opt/drwcs/bin/drwcntl ssl://%server-address%:10101 %username% %password% (можно запустить без аргументов – оно спросит реквизиты само).
3. Для какого-либо из проблемных агентов посмотреть в выводе "sftp vfs %station-id%" наличие AGENT или REAL. Важно: агент должен быть онлайн. Дальше повествование пойдёт на примере REAL.
4. Выясняем путь к проблемному файлу через дебри vfs. Тут может помочь команда sftp ls. Пользоваться примерно так: sftp ls real://%station-id%/. В моём случае я выяснил, что он должен лежать в real://%station-id%/data/Updater/repo/vdb-script.lua.lzma
5. Выходим из drwcntl и переходим к следующему снаряду, с которым удобнее скриптовать.
6. Вытаскиваем id всех подключенных станций: /opt/drwcs/bin/drwcmd --server ssl://%server-address%:10101 --user %username% --password %password% --commands 'clients ids' | grep -Ea '[0-9a-f\-]{36}' | sed 's%.*%sftp rm real://&/data/Updater/repo/vdb-script.lua.lzma%' > /path/to/tmp/file/with/commands
7. Должен был получиться список команд, удаляющий файл на всех станциях (наличие не проверяли, в целях экономии времени). Если оно визуально похоже на что-то адекватное – запускаем: /opt/drwcs/bin/drwcmd --server ssl://%server-address%:10101 --user %username% --password %password% /path/to/tmp/file/with/commands – в терминал вывалится куча сообщений про то, что файл не найден (где его не было) и про то, что удалось выполнить успешно.
И проверить, что всё отработало так, как нужно.