Проверка целостности системных файлов утилитой sfc

Проверка целостности системных файлов утилитой sfc 0.7.6

WMI включен и работает...
Походу либо Я Сам парюсь, либо сценарий...

......Текущий каталог: C:\5 ......

"C:\WINDOWS\system32\NOTEPAD.EXE" C:\WINDOWS\Logs\CBS\sfcdoc.log

Т.е. лог-файл создается в тек.каталоге и наполняется частично, тогда когда по окончанию сценарий открывает совсем др.файл(полный лог) совсем по др.пути...

+

......... Очистка хранилища завершено корректно
 
Последнее редактирование:
Т.е. лог-файл создается в тек.каталоге и наполняется частично, тогда когда по окончанию сценарий открывает совсем др.файл(полный лог) совсем по др.пути...

Изначально логи создаются и пишутся в каталоге WINDOWS\Logs\CBS\
Но иногда пользователи хотят сами видеть подробный лог и для их комфорта они копируются в текущий каталог (тот, откуда запущен скрипт)
По сути это одно и то же, никакого дополнения после копирования не производится.
 
Изначально логи создаются и пишутся в каталоге WINDOWS\Logs\CBS\
Угу, так оно и есть;

Но иногда пользователи хотят сами видеть подробный лог и для их комфорта они копируются в текущий каталог (тот, откуда запущен скрипт)
Не увидеть наверное, а скорее для удобства - например для дальнейшего предоставления на форум;

По сути это одно и то же, никакого дополнения после копирования не производится.

А вот тут неправда, т.к. -
Код:
:: Фильтрация
copy /y %windir%\Logs\CBS\CBS.LOG CBS.LOG
< "CBS.LOG" find /i "[SR]" | find /v /i "[SR] Verify complete" | find /v /i "[SR] Verifying 100" | find /v /i "[SR] Beginning Verify and Repair transaction" >>"%log%"
copy /y %windir%\Logs\CBS\sfcdoc.log sfcdoc.log

а после все остальное и wmic и sysinfo...
 
Кирилл, вчера обнаружил следующее:
если запускать по такому пути
c:\users\user_name\cloud@mail.ru
(это такая папка у пользователя), то консоль на долю секунды мелькнет и закрывается.
Из корня C:\ запустилось успешно.
 
Короткие пути - не панацея. Могут в некоторых случаях не работать, и это даже не из-за отключённого 8.3.
Я бы на твоём месте разобрался, почему возникает сбой с вариантом с примера Sandor. Там нет никаких спец. символов. Может оказаться, что причина в другом.
 
Я смоделировал ситуацию просто создав такую же папку.
Да, буду смотреть на чем срубается - думаю это из за не стандартного пути.
Практически все предыдущие замечания уже исправил.
 
Готов сообщить результат, который меня, честно говоря, сильно удивил.
Дело не в скрипте, не в коде.

Если путь к файлу сценария (bat файлу) имеет вид типа : *@*.ru , где вместо звездочек могут быть иные символы в разном количестве;
Если сам файл сценария (bat файл) имеет пробелы среди латинских букв ....
В таком случае файл можно запустить только с правами пониженными.
От имени Администратора - нет.

Решение - избавиться от пробелов в названии между русскими символами.

Sandor, благодарю за задачу)))

Ну и проверить бы на других машинах - я на своем компе все это проверял.
И версию Windows тоже неплохо было бы назвать.
 
Последнее редактирование:
Кирилл, у меня не получается воспроизвести проблему. В какую конкретно папку ты положил батник? Какая ОСь? Скрипт тот, что сейчас в этой теме?
 
Разобрался откуда ноги растут и почему у меня не воспроизводится.
Это вот этот баг: Наиболее частые ошибки, заметки особенностей программинга BAT файлов, баги интерпретатора* - Страница 3 - Batch (CMD/BAT) - Киберфорум
И символ @ согласно справки cmd /? тоже здесь считается спецсимволом.
А у меня в системе просто стоит собственный фикс из той статьи.
Проще всего будет сделать, как ты, говоришь, убрать пробелы из названия скрипта и архива, например, заменив на знаки подчёркивания.
 
А третья кнопка для чего?
fa3d11eb13381ba8af6571a502dabd71.jpg

+ батник запускал с рабочего стола, лог на него потом не скопировался.
OS: Microsoft Windows XP 5.1.2600 Service Pack 3 Build 2600 (VmWare)
 
Тут ничего не поделаешь, хочешь более широкой совместимости, приходится идти на жертвы.
Это в Win10 они немного подкручивают консоль.

Ну а в целом с другими ЯП похожие ситуации.

Видел как ты выкручивался в скрипте чистилки, применяя тот самый фикс реестра и затем перезапуском с повышенными привилегиями.
Но тут есть свои минусы:
- вносятся в систему изменения, о которых юзер не просит.
- при повреждении подсистемы wscript (которую скрипт Кирилла по идее тоже должен помогать лечить), этот самый батник не смог бы запустится, т.к. ShellExecute срабатывает через неё.

Так что вариант Кирилла с ручным запуском от Админа считаю наиболее оптимальным здесь.
P.S. Просто размышления "а что, если".
 
Последнее редактирование:
Dragokas, согласен с обоими утверждениями, но это тоже своего рода жертва, но в угоду удобству.

К слову, читаю:
как ты выкручивался в скрипте чистилки, применяя тот самый фикс реестра
И невольно делаю вот так о_О. Вроде мне адресовано, а я такого не делал !
Специально открыл и поиском нашел то место, где применяется фикс .. ага, точно есть. А как и когда добавлял вспомнить так и не смог :Biggrin:
 
Чуть выше приводил ссылку. Ты же сам эту багу тогда и нашел.
И через полгода писал первую версию чистилки.
 
Назад
Сверху Снизу