MSI repair not copying all files
The MSI/MST I'm working with installs per-user files to a "cache" folder under "Program Files" and uses DuplicateFile to copy to the user's %localappdata% folder. By doing it this way the MSI repair feature is not needed for the user that does the initial install.
If the files are deleted, they are restored via the MSI repair function from the "cache" location. But the files were being restored to different locations than where they were placed originally.
I noticed that the folder structure under the "cache" folder did not match the user profile folder structure. So I decided to try and fix this via Orca, modifying the MST, specifically the Directory and Component tables.
I modified Directory table entries and in a couple of cases created new entries if the Directory was shared with other components or was a parent folder for another directory. The component table directory_ column was modified to point to the new directory table key. This is the primary modification. Now the folder structure under the cache folder mirrors the structure under the users profile folder.However, the files moved into proper sub-folders under the "cache" folder are no longer being repaired.
There must be another aspect to the repair that I'm not aware of. Hoping someone can help with further hacks that I need to make to the MSI/MST.
Thanks
If the files are deleted, they are restored via the MSI repair function from the "cache" location. But the files were being restored to different locations than where they were placed originally.
I noticed that the folder structure under the "cache" folder did not match the user profile folder structure. So I decided to try and fix this via Orca, modifying the MST, specifically the Directory and Component tables.
I modified Directory table entries and in a couple of cases created new entries if the Directory was shared with other components or was a parent folder for another directory. The component table directory_ column was modified to point to the new directory table key. This is the primary modification. Now the folder structure under the cache folder mirrors the structure under the users profile folder.However, the files moved into proper sub-folders under the "cache" folder are no longer being repaired.
There must be another aspect to the repair that I'm not aware of. Hoping someone can help with further hacks that I need to make to the MSI/MST.
Thanks
0 Comments
[ + ] Show comments
Answers (5)
Answer Summary:
Please log in to answer
Posted by:
rileyz
8 years ago
Man I haven't used the DuplicateFile Table in ages, its a really efficient method of populating files into the profile though.
Just google'd this, some names I recognise! :D
https://www.symantec.com/connect/forums/files-self-healing-wrong-location-user-profile
https://www.symantec.com/connect/forums/files-self-healing-wrong-location-user-profile
Do you know where the files are going? Anyway, as I mention in other posts, LOG LOG LOG.
You'll probably need to enable via the MSI service (in the registry) so you can catch the repair logs, from there you can see whats going on. Off the top of my head, did you set a keypath (not sure if you do this for a DupFile), check the system profile just in case its getting copied there (if so read that link I mentioned). Start with the logs first as that will give you a good starting position, ie you can see if they are getting Dup'ed or not, if they are the log should tell you were they are getting copied too.
Posted by:
GTVic
8 years ago
Thanks for the link. I'm not sure if this is a repair, healing or active setup but I have found I can monitor the progress with Procmon and there is a log file.
I've determined the original MSI creates a key in the Installer area of the registry and creates a new MSI in C:\Windows\Installer\60d0836.msi.
When the product is "repaired" the 60d0836.msi file is the one that it runs. If you delete it an error occurs. It seems to copy all files from the cache location. It will even copy additional files that are manually added to the cache folder but not subfolders.
I tested this by renaming one of the files. It copied the renamed file and then complained the original wasn't there. As another test I tried modifying this MSI to change the name to the renamed file but that didn't get rid of the missing file message. None of the manual mods I made to this MSI worked so I still have no idea how the copying is done or what my next step would be to control this.
I've determined the original MSI creates a key in the Installer area of the registry and creates a new MSI in C:\Windows\Installer\60d0836.msi.
When the product is "repaired" the 60d0836.msi file is the one that it runs. If you delete it an error occurs. It seems to copy all files from the cache location. It will even copy additional files that are manually added to the cache folder but not subfolders.
I tested this by renaming one of the files. It copied the renamed file and then complained the original wasn't there. As another test I tried modifying this MSI to change the name to the renamed file but that didn't get rid of the missing file message. None of the manual mods I made to this MSI worked so I still have no idea how the copying is done or what my next step would be to control this.
Posted by:
anonymous_9363
8 years ago
Repairing/self-healing relies on key paths to identify what needs repairing. If the key path exists, no repair takes place. Simple.
Almost no-one I know uses this method to populate user profile data. Use a properly structured feature tree and advertised entry-points instead. If the MSI doesn't natively have any advertised entry-points then use Active Setup to trigger the self-healing.
Almost no-one I know uses this method to populate user profile data. Use a properly structured feature tree and advertised entry-points instead. If the MSI doesn't natively have any advertised entry-points then use Active Setup to trigger the self-healing.
Posted by:
GTVic
8 years ago
Top Answer
As this is someone else's install I can't change the basic way it operates. Since I don't have enough time to fully understand what makes this tick I've used a script to repair the problem when the user profile is reset or created. Thanks for the replies.
Posted by:
EdT
8 years ago
Using the duplicatefiles table can be quite complex as you rely entirely on key path detection to trigger the copying of files.
If you are working with Windows 7 or later, do bear in mind that the entire source of the package is now cached under c:\windows\installer although idiot Microsoft never bothered to have this location added as a source. If you do this yourself (I documented it on Symantec Connect) then you don't need to bother copying the files locally unless there is no advertised entry point in your package. (I have frequently changed shortcuts to be advertised when I want to enable self healing, but then you find out how bad the vendor MSI really is !! )