1334 runtime error with dynamic file linking

[Art Middlekauff]

Several users have reported situations where MSI runtime error 1334 appears when running a setup. These situations have the following elements in common:

- Using dynamic file linking.
- Using the "Previous Package" option in the Release View.
- Multiple files in the setup with the same name.

The only scenario I have been able to come up with that reproduces the problem is as follows:

Step 1. Create a base project as follows:
One feature with two components.
The first component has a dynamic link to a file "test.txt" (do not include subfolders).
The second component has a static link to a file "test.txt".
In Direct Editor, in the File table, note that the file key for the static file is "test.txt".
The Release should be a CD-ROM-based release with all files compressed. This will create a single external CAB that is easy to examine.

Step 2. Build the base project.
If you look at the File table in the MSI, note that the file keys are "test.txt" and "test.txt1".

Step 3. Modify the base project as follows:
Set the "Previous Package" release setting to the package from step 2.
Add a third component.
In this component, add a new static link to "test.txt".
In Direct Editor, in the File table, note that the file keys are "test.txt" and "test.txt1", both static links.

Step 4. Build the modified project from step 3.
If you look at the File table in the MSI, note that the file keys are "test.txt", "test.txt1", and "test.txt2".
However, if you open the CAB, you will see that the CAB contains a duplicate: "test.txt1", "text.txt", "test.txt1".

Step 5. Run the package from step 4. You will get a 1334 error complaining that "test.txt2" cannot be found.

This is a bug in InstallShield Developer and the bug tracking number is 1-ADGW5. I apologize to everyone who has encountered this bug.

Fortunately, there is a workaround. In the above scenario, the workaround is to modify the updated project. In the Direct Editor, in the File table, modify the File.File value from "test.txt1" to "test.txt0".

Hopefully this workaround will also work for large projects that have encountered the 1334 error. The way to identify the workaround is to examine the CAB (you can use a utility like WinZip to examine the CAB). Are there two files in the CAB with the same name? If so, find the corresponding entry in the File table of your ISM and change the trailing "1" to a "0".

Attached is a sample that follows the above steps and shows the 1334 error as well as an updated ISM file with the fix.

[TomClement]

Thanks for looking into this Art, and also for providing a clean workaround. This will make it possible for us to issue patches for our rather complex product.

Tom

(Of course, a complex product with lots of files is where this kind of problem is likely to occur, and unfortunately, that's also the type of product where patches are pretty critical.)

[breezer]

I've had this problem too, thanks for the workaround Art. I also have a very similar problem with dynamically linked files on a standard project under Developer 7.04 (and on win2000, in case that matters)

The CAB file has files:
beap.css
beap.css1
beap.css2
beap.css3
beap.css3
beap.css4

The msi file has File.File entries:
beap.css
beap.css1
beap.css2
beap.css3
beap.css4
beap.css5

Obviously this causes problems (two beap.css3's in the cab file, and the MSI DB names are unique and sequential). Each of these files is in a different feature (all at the same level, below a common grandfather feature in the tree). This is with previous package set to a package built with Developer 7.04, same as the new package. It's a compressed build (obviously, with the cab file).

The problem files are (as said before) dynamically linked files, and I use the "include subfolders" option. The affected files/entries are in the top level of the dynamically linked directories (does it put all files in subdir's into the "_<componentid>" named files in the cab file?). The duplicate files also appear to follow another pattern: one of them is from a feature in the old package (still in the new one); one of them is from a new feature added to the new package - so can't have it's file.file value "synchronised" with the old (previous version) package. Not a bug with the code to synchronise file id's not incrementing/storing the right count digit at the end of the name is it?

The duplicated beap.css3 in the cab file is attached to a component with a similar name (until the 20th character) and similar directory-name (the 12th char is different) as the other beap.css3 (which should probably be beap.css4 and the '4' renamed to a '5'?) - in the newly added feature.

I am wondering whether hacking the cab file is possible to try a fix out (renaming the affected files). But getting winzip to first extract the duplicate names without losing one of them, and then putting it back in with the name to match the msi record is rather tricky to say the least. Not something I want to do every release.

The exact same situation occurs with other files in the same situation (ie same names under different components in different directories), in fact for every file that has duplicate named files in the new feature. Several other features have files of the same name (all in the old package), but as you can see most of the rest are set fine and the lack of a '5' in the cab file is possibly just another side effect of the bug...

----------------------------------------------

SO is this part of the same bug (previous posts), and can I do anything about it? It's stopping me doing minor upgrades which I really hoped would be possible with SP4 after all the troubles with SP3 (and then you go and release Developer 8, with a tonne of bugs still left in v7...)

Is a workaround possible by getting all my dynamically linked files into the _<componentid> form in the cab file so they don't suffer from this bug (I hope)? Could I do this by somehow making the dynamic link point above the directory I want without including anything in that directory (specific file exclusions, ok as long as dir. contents don't change and don't match anything below that dir. either).

If any more info is needed about my install I'll be more than happy to supply it.

PS Please excuse my rather long post/edits to...

[breezer]

Just a note that anyone who's read my above post should re-read it as I've just edited it a tonne.

[Art Middlekauff]

breezer,

Thank you for your investigation and analysis. The problem you are encountering is basically the same as in the sample I posted, except your situation is a bit more complex and the workaround I posted will not work per se.

Probably the best workaround in your case would be to go to the offending component and put beap.css as an excluded file in the the dynamic-file-linking setting. Then add beap.css to the component using a static link. Then, you can go to the File table and change the key of that file to beap.css5 (or .css0), as in the original workaround I posted.

Trying to modify the CAB would of course by horribly inconvenient and I am confident we can find a simpler solution (hopefully what I suggested in the previous paragraph).

Forcing the _<guid> filename by redefining the dynamic link so that beap.css is in a subfolder would probably work. However, this may cause a problem if you want beap.css to be installed to, say, INSTALLDIR, because dynamic file linking with subfolders will create the subfolder that contains beap.css. There are tricks that could get around this, but it seems complex.

You are right that the current algorithm is to use _<guid> for dynamic files in subfolders, but to use <filename>x for dynamic files in the base folder. Judging from the hassle this has caused you and others it appears that this was a bad idea and we would be much better off using _<guid> for all dynamic files no matter what.

Please keep me posted on whether my first suggestion works. The 8.01 release will definitely have a fix for this, most likely always using _<guid> for file keys. Thanks again for your patience.