DesertJerry, on 07 July 2012 - 08:39 PM, said:
@_def_x: My point in running the tests I'm running is to verify the validity of the script and to determine if what is shown to be installed is accurate or not.
OK. Why are you doing it this way in the first place, slipstreaming may not put a cat file in place, may not write to the registry, AutoPatcher uses the cat file and the registry to detect the update, and of course the file if the update includes more than a registry entry. You're comparing apples and oranges. What would help is if an update is not being detected, if your file was slipstreamed - provide the alternative data to see if something can be done - this is my point.
You've reported a number of undetected files, if there's no cat file or no registry, the updated file should still be detected - how does your system differ from the detections in AutoPatcher? If you don't really care, why do you mention it in the first place - slipstreaming is different from the standard install in most cases, AutoPatcher uses the detections that work for the standard install - like I said before.
DesertJerry said:
I do not want to edit the APM files because that negates the test - and, for now, I'm not that concerned with what is installed or not.
That's how you beta test - try, if fail, edit, try again, reporting something is broke, without any details is pointless.
DesertJerry said:
Plus, because my installations have been with sources updated via slipstreaming/integrating I'm well aware there could be discrepancies between what I know is installed and what is being reported by AutoPatcher; that's the point of the tests.
This is the crux of the matter, you use a slipstreaming method, AutoPatcher uses Microsoft's installer. AutoPatcher (the release manager) puts in place a few detections based on the update, they may work for some slipstreamed updates but not all. When an update fails detection the fix is simple, provide your alternative, it really is that simple. Check the apm file, make note of the registry details, if yours differ, provide the alternative, or at least explain how the updates differ in a particular case.
DesertJerry said:
What has yet to be determined is if there is a way to reconcile the slipstreamed updates with the AutoPatcher script - that's why I referenced the NirSoft Windows Update List program.
... and again, how can anything be reconciled unless you provide details of how your update differs from the detections listed in the apm file. If you have another detection that works, nows the time, multiple registry entries can be used, only takes seconds to add it to the apm file.
Now, if you're not concerned, not sure of the reasoning behind mentioning all the failing updates, especially if you slipstreamed them and you expect the detections to fail - kinda pointless.
The fix I mentioned is the proper fix, and not a hack:
Doesn't work: FilePath=%Windir%\XXX\YYY\
Should work: FilePath=
windows:\XXX\YYY\
I also use Nirsoft tools, including WinUpdatesList. You should know that the lower pane offers details (for most updates), including file name, version, and the full path. If you are saying that the tool is detecting your update, is there any information given in the lower pane? If not, the detection is likely the registry, and again, for a particular update, if your registry is different from the one listed in the apm - it's incumbent upon you to provide details and not have someone else hunt down the info, if you want it to jibe with your system - otherwise don't mention it.
2
