Error 2920 (source dir not specified) while applying a minor upgrade patch onto a patched installation

Vitaly Dolya

2004-08-17 09:51:24 UTC

I've encountered the same problem. But i do not use InstallShield Developer
to prepare my installation.
So does any solution exist? I didn't seen any answer on that message in the
newsgroup...

Here patch-instllation log-file fragment (contain some russian characters
stuff but it doesn't matter):
-- cut --
MSI (s) (50:E4): Executing op: SetTargetFolder(Folder=C:\Program
Files\ASFPD\SURM\)
MSI (s) (50:E4): Executing op:
SetSourceFolder(Folder=1\ProgramF\ASFPD\SURM\|Program Files\ASFPD\SURM\)
MSI (s) (50:E4): Executing op: ChangeMedia(,MediaPrompt=Вставьте диск:
[ProductName]
,MediaCabinet=PCW_CAB_75C6EAB6,BytesPerTick=32768,CopierType=2,,,,,,IsFirstP
hysicalMedia=1)
MSI (s) (50:E4): Executing op:
FileCopy(SourceName=SURM.exe,SourceCabKey=SURM.exe,DestName=SURM.exe,Attribu
tes=4096,FileSize
=1277952,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,Version=2.8.811.68,Lang
uage=1033,InstallMode=59244544,,,,,,)
MSI (s) (50:E4): File: C:\Program Files\ASFPD\SURM\SURM.exe; Overwrite; No
patch; Existing file is a lower version
MSI (s) (50:E4): Source for file 'SURM.exe' is compressed
InstallFiles: Файл: SURM.exe, Каталог: C:\Program Files\ASFPD\SURM\,
Размер: 1277952
MSI (s) (50:E4): Re-applying security from existing file.
MSI (s) (50:E4): Verifying accessibility of file: SURM.exe
DEBUG: Error 2920: Source directory not specified for file SURM.exe.
MSI (s) (50:E4): Продукт: ASFPD -- Внутренняя ошибка 2920. SURM.exe
-- cut --

As far as i can see the 'SetSourceFolder' operation is pretty well executed
with right 'Folder' parameter...

Post by Frank Gales
Hello,
we have a severe problem which pops up as error 2920
Source directory not specified for file xyz.
xyz is the first file in the cab file.
We use InstallShield Developer 7.0 as IDE and the error occurs
in the context of a minor upgrade patch. But only in a certain context.
We released SP04 of our current major version as a full installation
as well as an upgrade (nimor upgrade patch -> msp file).
We are about to release SP05 (only minor upgrade patch but not full
installation) and are currently building the first
versions of SP06.
When we apply SP06 on an SP05 that we got via patch then we get the error.
SP04 --- patch ---> SP05 --- patch ---> SP06 -> XXX error XXX
When we use the internally available SP05 full installation and apply the
patch
everything is all right.
SP05 --- patch ---> SP06 -> no error
When we apply the SP06 patch on a SP04 full installation again no problem.
SP04 --- patch ---> SP06 -> no error
Now our assumption was that SP05 is the culprit.
We are also in contact with InstallShield support but we got no solution so
far.
Now I come to the nasty things we do. So maybe one of you specialists sees
the nonos we are doing and by that provoquing the error.
1 - When a file is no more needed or when it should be moved to different
folder
we use transitive components.
Example: SP04 File1/Dir1 (Comp1) -> SP05 File1/Dir2 (Comp2)
We give the Comp1 a condition that is allways false and we set the
condition to be
reevaluated (Bit 64 in the attributes of the comp).
Then we create a new component Comp2 for that same file with a different
destination
directory.
This is not really a clean approach but it was a solution that worked
allways in the past.
So I doubt this is the source of the problem.
2 - We had some explicit registry entries for a file File23. In
InstallShield Developer
you can also let the COM settings be extracted automatically during
creation
of the MSI file.
With a new version we had different registry entries.
We used our transitive component trick there also but as the two
versions
of the files would go to the same target directory we needed to have two
different
source dirs in the component table.
We did put an extra source dir not only for the new component but also
for the
old one. InstallShield created a new entry in the Directory table and
changed
the directory table link in the component table to point to the new
entry in Dir
table for the old component.
My first assumption was that this would be a change that was not allowed
(we changed the source dir of an existing component sounded matching the
error text somehow) but removing the changes rgd. a separate source dir
for
the old component did not help. The error still pops up in the same
constellation.
The RemoveRegistry table seems not to help as the removing is also only
done when the associated conponent is removed.
3 - We added the first .Net assemblies in SP06 and we had some warnings rgd.
these ones.
As it is allways the first file in the file ordering that belongs to the
features
to be reinstalled which is mentioned in the error message I assumed that
probably
the transform of the directory table could have gone wrong. But as I do not
have
any necessary information to move further to the solution I need some help
from
really MSI specialists. The verbose log did also not tell anything
interesting to me.
No SELMGR entry also that would tell me some oddities in feature components
relationship.
Sometimes MSI is quite frustrating.
One more thing.
Stefan Krueger writes on installsite that when a component is belonging to
two
features no change to this component is allowed. Can anybody confirm this?
Question is what is not allowed? Adding a condition to a component for
example?
If this would not be allowed would be a major restriction. That would even
kill
the already low flexibility rgd. changes during minor upgrades.
Thanks for any hints.
Greetings,
Frank Gales