Installer leaves a mess

#1
When I read "new installer version" I was excited ... maybe it'll stop leaving a mess in %TEMP ... not the case!
Code:
2014-12-22  22:26  480  {880FBB26-9B6A-4AA8-AB95-4C6A43ED3BFE}.bat
2014-12-22  22:28  735,110  MSIA66D.LOG
2014-12-22  22:28  441  EXE69A3.tmp.bat
2014-12-22  22:28  441  EXE69C3.tmp.bat
2014-12-22  22:28  <DIR>  777db8356beda08e2acf1fdf26cc6b7f
 
#3
Might those be marked for deletion on next reboot? (yeah, right. heh)

Something like SysInternals' PendMoves would tell you.

http://technet.microsoft.com/en-us/sysinternals/bb897556
I doubt it. The registry key for that is empty (and hasn't been used in years). And PendMoves finds nothing.

Each of the three bat files have an instruction to delete itself. One of them has an instruction to remove the (empty) directory. Note of that gets done.
 
#5
Just curious what makes you think that? Windows updates for one use the heck out of that feature because files that are in use need replaced.
Code:
v:\> keytimes hklm "filerenameoper"
2009-07-14  00:37:09  HKLM\SYSTEM\ControlSet001\Control\Session Manager\FileRenameOperations
2009-07-14  00:37:09  HKLM\SYSTEM\ControlSet002\Control\Session Manager\FileRenameOperations
2009-07-14  00:37:09  HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\FileRenameOperations
 
Jun 2, 2008
296
1
#6
Oh.. that's not the right place. I don't know what that is, but PendingFileRenameOperations is a value, rather than a key name, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager. Since PendMoves reports nothing, I believe that value might not even be there.
 
Jun 2, 2008
296
1
#13
That probably means that all the files that needed replaced could be done without having to restart Windows. You didn't have to reboot, right? Windows only processes that value when it's booting up, before anything has a chance to start and lock a file.
 
#14
That probably means that all the files that needed replaced could be done without having to restart Windows. You didn't have to reboot, right? Windows only processes that value when it's booting up, before anything has a chance to start and lock a file.
Right. I don't think TCMD updates use that mechanism anyway. But updates always leave that mess in %TEMP.