/build/static/layout/Breadcrumb_cap_w.png

Weird DuplicateFile/RemoveFile Behavior...

Hi all,

I noticed some odd behavior while testing some parts of our installation that deal with DuplicateFile and RemoveFile tables.  There are some entries that act on files/directories that have no other components installed to them.  The directory entries for these are contained in the Directory table.

The same setup exists in the MoveFile table and files do end up where they are supposed to be at runtime.  During install, the DuplicateFile entries do their job as well.  So, post install, everything is duplicated/moved (copied) as expected.

Now, on uninstall, all other files in our app that are associated with DuplicateFile or RemoveFile entries are taken care of properly.  There are these assigned to a directory where no other components are installed that still remain.  The way that I have found to get around this is to simply add a component (using InstallShield 2013 by the way) and assign it to this problematic directory.  I do NOT have to make any association in either table in question to this new component to have it work properly.  Just adding the properly caused everything to be removed as expected.

I should also state that before adding the new component, the trigger components used in the tables are removed properly on uninstall, but their associated/copied files are not.

What throws me is that on install, everything is OK copying to this directory, but removal has a problem.

Here's a little explanation on this directory I speak of.  It is part of a third party app file system where we have to shove some files.  We detect the third party install location and set a directory in our app for the copies...  C:\Thrid Party\Application\Dependencies.  This Dependencies folder is the target for the copies.

So, in summary, no problem on installs, weird(?) behavior on removal.

Does anyone know if this is normal behavior - for removal through these tables?  There has to be an actual component tied to the target directory as part of the install in some fashion.   This component, again, does not have to be used in the tables themselves, at least that is what I am seeing.  ?????

Asked 9 years ago 1190 views
9 Comments   [ + ] Show comments
  • could you have a quick read of your question, making sure the facts are there. Are you working on a vendor MSI?? is there a RemoveDuplicateFiles Action present in the installexecute seq table?? - Badger 9 years ago
  • It is our .msi. The action is in place because there are many table actions that are executed properly. There are other table records that are handled properly. The problem is only tied to the target directory that has no actual components tied to it. Again the directory is present in the directory table and during install the DuplicateFile and MoveFile table entries go where they need to be.

    I thought I had tested all the removes on uninstall before and they were all working properly. Adding the component directed to the directory in question solved the problem. If you are familiar with InstallShield, all I did was create the component and ensured it pointed to the Dependencies directory. I didn't add any files, reg entries, etc to it. It's basically an empty component. - Superfreak3 9 years ago
  • So I have all the removes working properly now after adding those empty components. Why it's needed, no clue, but if it works I guess its good. I did notice another problem I have with the MoveFile table now. Again, I thought this part of it was working as well. During initial install, all the files that are needed are moved (copied) as desired. However, in using a Maintenance (Modify) install to add features, the MoveFile entries associated with these features through their components are NOT happening. What the heck is going on now? The Modify would be needed because the features will not be installed unless a third party app (reg entries) is present. So, if a user upgrades the third party app after installing our software, we run a Modify to place our associated components. I don't see any conditions on the MoveFiles action so it should be running. The components on the features being added, and those used in the association in the MoveFile table are installed as expected during the maintenance install. ??? Also, I verified that I see this undesired behavior in a package that does not contain the latest addition of those empty components. - Superfreak3 9 years ago
  • Its very strange. We have Moves that should end up in Dependencies\fr-CA, which do for both initial install, when third party app is present, and during Modify (Maintenance) when the third party app is updated after install our software.

    However, none of the Moves are occurring for the Dependencies folder. I'm positive this was all working before. No clue what could be going wrong or when it might have happened.

    When I log the mnt install, I do see the reference to the MoveFile for the highlighted items but nothing for the others. Maybe I should check that the Directories are hashing out correctly from the log. - Superfreak3 9 years ago
  • To be honest, having read your original and subsequent postings, all I get is a lot of waffle but nothing specific I can get my teeth into. I would refer you to the SDK help file MSI.CHM as I have done many times when you posted in the Altiris Wise forums. With DuplicateFiles, the SDK will tell you that the action of the DuplicateFile table is completely tied to the component holding the master file. If the master component is not installed for any reason, the duplicate file will not be installed either. You need to consider and test these actions in the install repair and uninstall scenarios. In addition, if you generate a property value during install based on a search or anything else, you need to set up an uninstall action that regenerates this property so that it remains available. When it comes to Installshield, this tool traditionally uses a lot more custom actions than the Wise product ever did, and this can make the bahaviour of the MSI less predictable. So ultimately, if you have found a solution by generating empty components, chances are there is something bizarre going on with Installshield. - EdT 9 years ago
    • OK, here is some more information. The MoveFile issues during Mnt. appears to be cleared up. What I did find with the RemoveFiles issue is this. There are a chunk of records that are not being removed even though the associated component are removed. This scenario presents itself when removing from Add/Remove Programs. If I execute the .msi again to force Mnt and select Remove - Everything is gone as expected!! What the heck is the difference? And, with this in mind, the associated components are gone. I hope this lights a bulb for someone! - Superfreak3 9 years ago
  • I think I have found the problem with the MoveFiles situation during MNT install. After examining the logs I noticed that several of the directories involved in that table were not being set properly. I then noticed that I had some Set Directory CAs that were conditioned with NOT Installed, which should have been NOT REMOVE="ALL". This would explain why the behavior was correct or desired during initial install, but didn't work during Mnt. I am aware that the Moves won't take place unless the corresponding component from the table is installed. The components were being placed during mnt, but since the directories were wrong for the Move source, the files could not be found so it gave the appearance nothing was happening. I tried to be as detailed as possible, but my head was spinning as it appeared everything was crumbling. I'm recompiling all of the involved installations now and retesting. Hopefully all will be good. - Superfreak3 9 years ago
  • EdT, your comments got me to thinking. It seems that some of the Directory Set actions needed to run on Uninstall as well to clean things up appropriately so I think you for that. I believe when I test this stuff before, I was doing so strictly through the UI. Removing from Add/Remove Programs was where the problem was seen. On a different, does anyone know what comment was hidden and why? - Superfreak3 9 years ago
  • Checking verbose logs during install and uninstall can be most helpful in determining if directory properties are being resolved correctly. As for the hidden comment, check the link to the FAQ as this describes the range of situations where the post may be hidden. - EdT 9 years ago
  • Yes, I am the first to admit that I still haven't drilled into my head to CHECK THE LOGS FIRST (after all these years)!!!! I wish there was a Windows Installer certification course. It's a science in itself! There were a few books on the subject, but I think they dealt with the 2.0 version range. But, I digress - THANKS EVERYONE for setting me straight!! - Superfreak3 9 years ago

Answers (0)

Be the first to answer this question

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ