SparkleFlow is the acclaimed packaging solution that combines all aspects of a software packaging project into a single interface. Preparing an application migration? Need to reduce your TCO? Need to manage lots of applications? Want to setup your applications right now and not waste to much of your value time? SparkleFlow Package Management offers the complete solution for creating structure in your packaging project.
Written by Manfred van Poorten
Description:
ICE30 validates that the installation of components containing the same file never installs the file more than once in the same directory.
The target file <FileEntry> is installed in <DirectoryEntry> by two different components on an SFN system: <Component1> and <Component2>. This breaks component reference counting.
Concerns:
ICE30 goes to every component in the Component table and then determines the component's target directory from the Directory table. It then checks to see which of these components install to the same target directory. Finally, it uses the File table to verify that none of the files in these components have the same name.
ICE30 checks both long file names (LFN) and short file names (SFN).
ICE30 does not evaluate properties in the resolution of directories because these properties can change at runtime and alter the directory resolution scheme. This means ICE30 can detect file collisions due to directories with the same property in their paths, but does not detect collisions resulting from two properties having the same value.
Additional Information:
You will seldomly find this error in relation to re-packaging. It only occurs in a few cases, for instance in the case of a repackage (with smartmonitor) of a vendor setup.exe with service pack or with a update which is created in a single snapshot. It occurs more often with vendor-MSI's.
The error indicates that there are components which are installed in the same directory as well as files that hold the same name.
Examples of possible errors:
In case you wish or need to resolve this error, keep in mind the following:
Error 1: is a problem indeed.
Image an application “MSI1” which is comprised of two features: “ProgramFiles” en “HelpFiles”.
“Component1” is located in feature “ProgramFiles” and “Component2” in feature “HelpFiles”.
The file called “File1.exe” is placed in the directory “Directory1” by both “Component1” and “Component2”.
In case only feature “HelpFiles” is to be removed , windows installer would remove the file “File1.exe” from the system (ref count for Component2 equals “0” indeed), while this file is also used by component “Component1” located in feature “ProgramFiles”!
When starting up the application it will trigger self-repair and re-install “Component1”. in case this file constitutes the key of the component. Otherwise, the error may display a message “file not found”.
Error 2: the same as error 1. The only difference is that a condition may be included in one of the components.
Error 3: This is sometimes used in Vendor MSIs for instance, to put a file that holds the same name but differs in contents for Win95/98 and WinNT/2K/XP. The condition of “Component1” would then be e.g. “Version9X” and for “Component2” the condition would be “VersionNT”. As a result, the file that is being placed would then become OS dependent. Note that this is a warning, not an error.
» Back to article overview