Jump to content


Verify Installers Flag


3 replies to this topic

#1 TroLL

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 10 August 2010 - 08:36 PM

It appears that the default operation when running AutoPatcher is that it scans for what updates it has, scans to see if their installed, then verify the installers with what I assume is a MD5 check regardless if its installed, then prompts for which updates to install.

Verifying over a slow network on a slow computer, this process takes painfully long for a single update or no update at all.

I request a flag for the verification process with options to:
1. Disable all together
2. Verify only if installing, after choosing what updates to install
3. Verify only if not installed pre-choosing of updates
Of course, if no flag verify all as normal.

Thanks for a great program and all those that maintain the update lists, best alternative around for Automatic Updates!

#2 Cristiano

    Super Helpful Guy

  • Veterans
  • PipPipPipPipPipPip
  • 3,851 posts
  • Gender:Male
  • Location:Brazil (Santa Maria - RS)

Posted 10 August 2010 - 10:06 PM

please, do not run autopatcher from network folders. this is the very reason for an know issue that never was fixed

about that routine, you are right. there's an easy and fast way to speed-up the process a lot. first of all, run autopatcher as it was downloaded in one computer and check for integrity with the provided md5 file or running autopather. after be sure that the download is ok, just remove the .rti files. it will turn your version into unofficial, but it will decrease a lot the loading time in slow computers. oh yes, the checking for already installed updates doesn't take a second, without those files

this you may find useful too:
4 - Commandline Arguments
Commands you can pass to AutoPatcher.exe via the command line to alter default behaviour.

? Shows a message about the available switches
help Shows a message about the available switches
nolicense Skips both the AutoPatcher and Microsoft licenses
nocrashhandler Disables the crash handler
log Enables active file logging (to <windows>\autopatcher.log)
report Used along with /log, adds an installation report to the log file
verbose Enables additional output that /log would not normally write
devmode Allows you to ignore errors (in crash handler)
noreboot Skips the reboot sequence (Not implemented yet fully)
nodetection Skip file and registry detection on modules. Everything will be as if it's not installed, even if it is!
english Overrides the user interface language (normally adapts to regional settings) and switches it to default, english.
answerfile:<filepath> Specifies an answer file to load. This overrides the Answer File screen (where AutoPatcher would normally detect answer files in its folder and ask you whether it should load any of them)
unattend Activates unattended installation (implies nolicense). This also skip the answer-file screen, so the only way of specifying an answer file is through the answerfile switch.
minimal Only used along with unattend. This will run AutoPatcher with a minimal UI.
recommended Normally only modules marked as critical will be checked by default in the selection window. This switch allows modules marked as recommended to be checked by default too.
neverselectinstalled Installed child items of a parent will not be selected when the parent is marked for installation (normally selecting a parent will also select ALL children, even if installed/blue).
slipstream:<share> Allows you to integrate patches into installation media, where <share> is the drive and path to the share. This disables detection (no point detecting what is installed on the running system since the patches will be applied to a share), removal (can't remove an integrated patch from a share, can you?) and environment checks (e.g. windows version, language, ie, wmp -- for the same reason that detection is ignored).

[]s

#3 TroLL

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 12 August 2010 - 06:10 PM

Thanks for the info, this has the desired effect.

I found if I deleted these files and ran apup.exe again it would give and error and recreate the file. So in turn I created a little AutoITv3 script to rename the file to its proper name, launch apup.exe and when it closed rename the file with .rt_ extension so when autopacher.exe runs it would skip the verification and keep a copy for the next time apup is run.

I tired the /auto flag on apup.exe but it would stay open on error so the script also handles the pressing of next, closing and any errors that popup(at least the ones I ran into during testing). The apup.exe is set to remember last selections.

The idea is to fully automate the updating so I don't have to worry about it. Set the AutoIT script in TaskScheduler and forget about it.

I also keep separate copies of AutoPatcher for different purposes. This would keep the verification time down if I only wanted to update one thing. For that reason script is set to run on multiple sub-directories. I suppose this really isn't needed anymore, but old habits die hard.

Below is a copy of my AuotIT script. Hope this is of use to someone. Please be kind about my code, I'm not a programmer.


dim $apup[4]
$apup[0]="AutoPatcherDotNet"
$apup[1]="AutoPatcherOffice07"
$apup[2]="AutoPatcherXP-SP3"
$apup[3]="AutoPatcherExtra"
$loc="C:\share\"

For $i = 0 to UBound($apup)
	$fullloc = $loc & $apup[$i]
    FileChangeDir($fullloc)
	if FileExists("*.rt_") Then
		$search = FileFindFirstFile("*.rt_")  
		While 1
			$file = FileFindNextFile($search) 
			If @error Then ExitLoop
			if $file <> "apengine.rti" Then
				$newfile = StringReplace($file,".rt_",".rti")
				FileMove($file, $newfile)
			EndIf
		WEnd
	
	EndIf
	Run($fullloc & "\apup.exe",$fullloc & "\")
	WinWait("AutoPatcher Updater")
	;Pause to allow AutoPatcher to read settings file
	Sleep(2000)
	ControlClick("AutoPatcher Updater","","[CLASS:ThunderRT6CommandButton; INSTANCE:3]")


	do
		;Error Handler: hit ok if error
		if WinGetClassList("Verification Failed") Or WinGetClassList("Application Error") Then
			ControlClick("Verification Failed","","[CLASS:Button; INSTANCE:1]")
			ControlClick("Application Error","","[CLASS:Button; INSTANCE:1]")
		EndIf
		
		$test = WinGetClassList("AutoPatcher Updater","Finish")
		sleep(5000)
	Until $test <> ""

	ControlClick("AutoPatcher Updater","","[CLASS:ThunderRT6CommandButton; INSTANCE:3]")
	WinWaitClose("AutoPatcher Updater")
	
	FileChangeDir($fullloc)
	if FileExists("*.rti") Then
		$search = FileFindFirstFile("*.rti")  
		While 1
			$file = FileFindNextFile($search) 
			If @error Then ExitLoop
			if $file <> "apengine.rti" Then
				$newfile = StringReplace($file,".rti",".rt_")
				FileMove($file, $newfile)
			EndIf
		WEnd
	
	EndIf

Next



#4 yorkshirepudding

    Newbie

  • Members
  • Pip
  • 2 posts
  • Gender:Male
  • Location:Newcastle-upon-Tyne, United Kingdom
  • Interests:All things computers, motorbikes, and the usual family etc.

Posted 26 November 2011 - 03:19 PM

Hi Troll. Very helpful script thanks. I hadn't heard of AutoIT but had started wondering how I could automate the running of apup. I currently run apup on my main computer, then use a batch file to xcopy the files to the network store. Then from the other computers, I download from the network store (another batch file), then have to run apup again to stop the unofficial release message, and to ensure it works, then run autopatcher on each of them. I have now downloaded AutoIT and seeing how much I can automate.

Thanks
yorkie





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users