[Klezk]

при "методе /integrate" в папке I386 обновляются существующие файлы, а в SVPACK добавляются те файлы которых нет в исходном дистрибутиве, а также цифровые подписи обновлений.

Сейчас еще раз проверил - в SVPACK добавляются ИНСТАЛЛЯТОРЫ ПОЛНОСТЬЮ, слегка переименованные (восемь букв на имя файла)! Так что вопрос остается - если запускается инсталлятор, то зачем тогда было заменять файлы в папке I386? Они все равно заменятся, когда сработает инсталлятор!
Выходит - метод /integrate фактически включает в себя полностью метод SVPACK ПЛЮС еще непонятно для чего сделанные телодвижения - вынимание из инсталляторов цифровых подписей и длллек, заменяемых в I386!

И еще: интегрировать обновления методом /integrate нужно в определенном порядке или не имеет значения?

Насколько корректно работает RyanVM's Windows XP Post-SP2 Update Pack http://www.ryanvm.net/msfn/updatepack.html ???

[Petya V4sechkin]

Klezk

Производил интеграцию обновлений методом /integrate и наблюдая за происходящим заметил вот что: само обновление (укоротив имя) помещается в папку svcpack, а ИЗВЛЕЧЕННЫЕ ИЗ НЕГО всякие дллки идут в папку I386 ВМЕСТО бывших там старых. Вопрос, извините, если еретический: а зачем, собственно, Microsoft устанавливать за 13 минут до окончания установки винды все обновления из папки svcpack (ориентируясь по файлу svcpack.inf) ЕСЛИ ФАЙЛЫ _У Ж Е_ ОБНОВЛЕНЫ В ПАПКЕ I386 ?! Дллки, *.sys и прочее ведь уже исправлены в I386!!! Хоть убейте, не могу я понять логики! Объясните, кто в курсе!

Да, логику тут увидеть трудно :)
Можно несколько причин назвать:

• при установке обновлений вносится информация в реестр из inf-файлов;
• в некоторых обновлениях (например KB922120) предусмотрены вспомогательные действия (выполняемые опять-таки из inf-файлов);
• есть такая папка %windir%\$hf_mig$. При установке обновлений в нее записываются QFE-ветки (хотфиксы) на тот случай, если... Тяжело объяснять, почитай этот пост.

Так что вопрос остается - если запускается инсталлятор, то зачем тогда было заменять файлы в папке I386? Они все равно заменятся, когда сработает инсталлятор! Выходит - метод /integrate фактически включает в себя полностью метод SVPACK ПЛЮС еще непонятно для чего сделанные телодвижения - вынимание из инсталляторов цифровых подписей и длллек, заменяемых в I386!

Для некоторых обновлений и хотфиксов желательно их присутствие в дистрибутиве еще на фазе установки, например:

• если компьютер в локальной сети, полезно закрыть критические уязвимости (чтобы вирус не залез);
• хотфиксы типа KB885626 или KB883667 могут решить специфические (редко встречающиеся) проблемы.

И еще: интегрировать обновления методом /integrate нужно в определенном порядке или не имеет значения?

В редких случаях (когда файлы из разных обновлений пересекаются) метод /integrate может быть чувствителен к порядку.

[Vadikan]

Petya V4sechkin
Спасибо за развернутый ответ

И еще: интегрировать обновления методом /integrate нужно в определенном порядке или не имеет значения? В редких случаях (когда файлы из разных обновлений пересекаются) метод /integrate может быть чувствителен к порядку.

Ты имеешь в виду случай, когда, скажем, одна и та же библиотека входит в состав разных обновлений и соответственно имеет разные версии в этих обновлениях (или более экстремальный, когда у человека собрано N обновлений, часть из которых уже была заменена более новыми, и в идеале список должен содержать N-k обновлений)?

А разве update.exe не учитывает версию, если используется ключ /integrate? Ведь при установке это учитывается, поэтому я думаю, что и при интеграции поведение должно быть аналогичным.

The software update installation begins from the extraction directory that was just described. The Update.inf configuration file that is a part of the package installer includes the installation logic and registry changes that are required to install the software update. The package installer identifies which files to install and examines the currently installed versions of those files. If the current version is the same as or newer than the version being installed, the package installer does not update the file. In rare cases where the version numbers are identical, but the file hashes are different, the package installer updates the file.

Inside update.exe Я пробежался по статье... Процесс интеграции в ней как-то очень кратенько описан, и конкретно данный вопрос вроде не освещен.

[Petya V4sechkin]

Vadikan

Ты имеешь в виду случай, когда, скажем, одна и та же библиотека входит в состав разных обновлений и соответственно имеет разные версии в этих обновлениях (или более экстремальный, когда у человека собрано N обновлений, часть из которых уже была заменена более новыми, и в идеале список должен содержать N-k обновлений)? А разве update.exe не учитывает версию, если используется ключ /integrate? Ведь при установке это учитывается, поэтому я думаю, что и при интеграции поведение должно быть аналогичным.

Прошу прощения, что не пояснил свою мысль.
Я имел в виду коллизии типа KB885250 + KB885835 (хотя они оба сейчас уже не актуальны, поскольку перекрываются более новыми). Также, некоторые файлы не имеют информации о версии (типа sysmain.sdb или ntldr). Как в этом случае поведет себя установщик, я не знаю.
Но это действительно редкие случаи.

[Vadikan]

Petya V4sechkin
Ок, так и запишем

[tel_b]

http://www.oszone.net/2755
написано
Все файлы обновлений должны быть переименованы в формат 8.3 (не более 8 знаков в имени файла + 3 знака на расширение).
сейчас есть файлы
KB2544893.exe
KB2378111_WM9.exe
KB951376-v2.exe
KB942288-v3.exe
интеграцию я сделал /integrate
это файлы из папки svcpack, получились автоматически
если не соблюдается (не более 8 знаков в имени файла + 3 знака на расширение).
это както отразиться на работе собранного диска?