I've been scratching my head about this one, and have googled around for answers, but didn't find anything interesting - I am sure it's probably a matter of my search terms at this point, but I hope someone out there knows why I am seeing this behavior.
I am looking to link an msi install to it's corresponding \Windows\Installer\msi_munged_file_name.msi. I use /l*vx logging to get the MSI install log, and I see an entry like this:
PROPERTY CHANGE: Adding DATABASE property. Its value is 'C:\Windows\Installer\1f219540.msi'.
And I watch as the file system does indeed get that file created. But, after MSI finishes, the file gets renamed. o_O
I've gone through 2 iterations of this, and both times the file has been renamed to what it was before +3 hex, I think. So, in this case I wind up with a file named:
C:\Windows\Installer\1f219543.msi
I am curious as to why the rename happens, and if the algorithm is to indeed +0x3 the last character in the file name, or if this is just coincidence on my 2 runs so far.
I've used Orca.exe to verify that the file that results in C:\Windows\Installer is indeed my msi.
This is for research I am doing on Windows Installer, and I am trying to better understand the MSI/Windows Installer platform.
Thanks in advance!
I found a way to get what I needed. It appears that during an install, Windows Installer performs a "transform" on your product code - I found this referred to as a "packed GUID" - it's an odd (to me) reversal of sorts on the product code GUID. There are many references to this out there.
So, I wrote code to take a product code GUID, "pack it" to get to the key:
You can then read the value for LocalPackage and have your full path to the locally cached MSI file.
I learned a great deal about Windows Installer via this exercise.
Assuming you're using signtool, you have to include the option flag
/d MyProduct.msi