А детальное ТЗ будет или это всё на уровне обсуждений?
Наверное обсуждение - важная часть, которой я ждал от тех, кто проявит желание.
У меня уже было несколько совершенно четких ТЗ, но все они оказались не годны.
Исходя из этого я и разместил общий план действий.
На счет версионности.
Те файлы, которые окажутся более старой модификации останутся работоспособными, так как в каталоге безопасности системы они должны все равно числиться.
Если что то потребуется очень уж сильно обновить до последней модификаций , например тот же DISM - можно либо накатить обновление заново, либо брать изначально актуальную версию файла.
Тут логика у меня такая: если в каталоге безопасности старая модификация должна числиться и быть работоспособной, то в обратном случае, когда файл не будет считаться родным мы получим как минимум "не удалось восстановить некоторые из них..."
Сразу предвижу вопрос: зачем, если результат не гарантирован?
Ответ: толк есть если покоцан файл, ссылка в реестре или файл в хранилище отсутствует.
Это наиболее распространенные варианты.
То есть если у человека проблемы в работе системы и ее эксплуатации - то до рабочего состояния система будет восстановлена.
Это на мой личный взгляд на сегодня самый лучший вариант, так как восхваляемые в сети патчи DISM для той же Win 7 вовсе не выполняет тех задач, о которых все под копирку пишут.
То есть он лишь сверяет имеются ли повреждения фалов в хранилище и выводит в лог.
Причем делает это не всегда корректно.
Самым лучшим информатором по прежнему остался CBS.log.
Причем общепринятый парсинг по строке [sr]
findstr/c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfcdetails.txt
оказался тоже малоинформативен на сегодня и почти всегда нужно просить все равно полный лог.
Тот вариант парсинга, что я предлагаю позволит собирать более полную информацию и статистику по улучшению качества удобочитаемости парасера.
И завершу ответ обобщенным вариантом команды:
sfc /SCANFILE=*.* /OFFBOOTDIR=d:\ /OFFWINDIR=d:\windows
Это, если кто не помнит или не в курсе, как раз таки команда восстановления из автономного каталога, который, по моему мнению будет представлять из себя подключенный образ Wim.
Всю работу по сопоставлению легитимности файлов должна брать на себя утилита.
Мы лишь используем ее возможности.
Тут я как то плавно перешел к тому, что мы получаем новые возможности при работе с Wim - необходимость проверки в режиме среды восстановления благодаря этому сведется почти к нулю, за исключением случаев, когда необходимо заменить файлы используемой системой.
Да, упустил - на время работы с хранилищем на каталог Log и WinSxS даем права админу.
Есть еще файлы, не защищённые SFC. Они тоже подвержены повреждению. Можешь выдернуть список через HiJackThis. Их можно тоже проверить, например, через валидность ЭЦП.
На счет этого были мысли, но абсолютно где то там на будущее))
Если и это будет в обсуждении - я за.
А решать эту проблему не пробовал?
Мне кажется эта проблема не имеет отношения к восстановлению файлов, поэтому выкидываю из лога.
Что это за каталоги и на что влияют?
Это каталоги, в том числе из которых производится восстановление файлов.
Поэтому когда в логе светится соответствующее сообщение - проверяем кто пустой.
Сопоставляем со строкой потому что будет сложно определить что там должно было находиться без остальной части лога.
Если какая то папка пуста, система никак не сможет восстановить файл.
Я пока еще определяюсь с принципом ссылок на них в реестре, поэтому пока только проверка на пустые при записи file missing
Можно ещё выполнить команду отката обновления, если знать, какой файл в каком из них.
Когда будет сопоставление строк по логу по части имени - мы это будем наглядно видеть, что сделает скрипт действительно сильным инструментом.
Это если в образе есть соответствующая версия. А пропатченый обновлением файл ты откуда будешь дёргать?
На этот вопрос уже ответил выше, разве что добавлю момент - хочется видеть о таких файлах информацию о версии,хэш,эцп... для тех, которые не удастся восстановить по описанной системе.
Для доработки следующей версии скрипта.