угу, самое забавное при удалении обратил внимание на дату изменения 31 сентября, т.е. вроде и не менял сертификат, но потом зашёл в загрузки браузера и таки 4-го октября была скачка сертификата и папка загрузки C:\Program Files\BOINC может и нло существуют?

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

скорее всего, странно что предупреждение не появилось

снова не получает задания, теперь пишет постоянно
15.03.2022 23:12:51 | | [network_status] status: don't need connection

снова не получает задания, теперь пишет постоянно
15.03.2022 23:12:51 | | [network_status] status: don't need connection

Some of the Servers are in Russia and as you are aware alot of their internet is having 'issues' right now, that has made me responding here from the US almost painful, but to your problem...when it says "don't need tasks" it means your other Projects have already filled your cache on that pc, one thing that does work sometimes for me when that happens is I Suspend all other Projects and then click Update in the Boinc Manager pane that lists all the Projects. As I said sometimes it works and sometimes it doesn't, it depends on how close to being totally full your cache already is. My cache is set to 0.5 and 0.25 so I never have alot of tasks anyway, one workaround for me is to increase the cache size, WHILE all the other Projects are suspended, then click the Update button again and see if you get some tasks, if you do you can then reduce your cache size and then unsuspend all the other Projects.

заработало, с сервером что-то наверно или с инетом, как вы написали

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

скорее всего, странно что предупреждение не появилось

Знаю, что сообщение старое, но может кому пригодится, т.к. неочевидная проблема. Это "приколы" от службы виртуализации файлов Windows. http://msdn.microsoft.com/en-us/library/windows/desktop/bb756960.aspx

По умолчанию (если это отдельно не отключить через реестр или групповые политики), когда какая-то программа НЕ имеющая прав администратора пытается что-то записать в защищенную папку (в которую можно писать только с админскими правами), она не дает отлуп с ошибкой "НЕЛЬЗЯ!", а вместо этого создает для этой программы виртуальное хранилище (по умолчанию оно в Users\текущий пользователь\AppData\Local\VirtualStore\) и пишет файлы туда.
Когда эта же программа пытается его из той папки прочитать - она его отдает назад. Но никакие другие программы больше этот файл не видят, т.к. на самом деле он лежит в совсем другом месте. Ну а если он там уже был, то видят его исходную/предыдущую версию. А замененную видит только та программа, которая пыталась его заменить (т.к. конкретно для нее чтение тоже переадресоывается на ее персональное виртуальное хранилище).

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

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

P.S.
У себя я эту функцию отключил полностью - пусть лучше программа сразу вываливается с ошибой (из-за невозможности записать файл), чем потом ломать голову почему что-то не работает/не обновляется из-за файла улетевшего в виртуальное хранилеще.
А паре старых программ которым все-таки это оказалось нужно вместо этого просто выписал права на доступ. Только не полный админские(что плохо с точки зрения безопасности), а конкретно просто разрешение на запись к конкретному папке/файлу которые им были нужны для работы.