MSI error 2920 "Source directory not specified for file" when patching
Jason Swager
I'm pretty sure that I've observed all the MSI rules about upgrades and
patching. Several patches (minor upgrades) have successfully been built and
applied to installations.
However, the latest patch will suddenly no longer work properly. Every time
the patch is applied, it fails with MSI error 2920 "Source not specified for
file X", then executes a rollback of the patch. I know that the file is in
the patch; I saw it get compressed during the MSIMSP run and the generated
log file indicates that it is being put into the patch. But for some
reason - it won't install.
The following is a snippet from the log file that was generated during the
patch operation:
<SNIPPET>
MSI (s) (3C:38): Executing op:
FileCopy(SourceName=AvBackup.exe,SourceCabKey=AvBackup.exe,DestName=AvBackup
.exe,Attributes=4096,FileSize=65536,PerTick=32768,,VerifyMedia=1,,,,,CheckCR
C=0,Version=2.1.38.0,Language=1033,InstallMode=58982400,,,,,,)
MSI (s) (3C:38): File: C:\VMail\AvBackup.exe; Overwrite; No patch;
Existing file is a lower version
MSI (s) (3C:38): Source for file 'AvBackup.exe' is compressed
InstallFiles: File: AvBackup.exe
Directory: C:\VMail\
Size: 65536
MSI (s) (3C:38): Re-applying security from existing file.
MSI (s) (3C:38): Verifying accessibility of file: AvBackup.exe
DEBUG: Error 2920: Source directory not specified for file AvBackup.exe.
Internal Error 2920. AvBackup.exe
MSI (s) (3C:38): Product: Repartee for Windows -- Internal Error 2920.
AvBackup.exe
Action ended 9:54:48: InstallFinalize. Return value 3.
</SNIPPET>
Does anyone have a clue as to why this is happening or how to go about
solving it?
Jason Swager
Rich [Microsoft Windows Installer MVP]
"Jason Swager" <jason-...@activevoice.remove-me.com> spake the secret code
<#TKze0IM...@TK2MSFTNGP09.phx.gbl> thusly:
>DEBUG: Error 2920: Source directory not specified for file AvBackup.exe.
>Internal Error 2920. AvBackup.exe
>MSI (s) (3C:38): Product: Repartee for Windows -- Internal Error 2920.
>AvBackup.exe
>
>Action ended 9:54:48: InstallFinalize. Return value 3.
></SNIPPET>
>
>Does anyone have a clue as to why this is happening or how to go about
>solving it?
Did you try visualizing the changes of the patch by loading the base
product in Orca and then applying your patch? Check the relevant
entries in the File, Component and Directory tables for this file.
--
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
<http://www.xmission.com/~legalize/book/>
Pilgrimage: Utah's annual demoparty
<http://pilgrimage.scene.org>
Jason Swager
patches had been built and applied using the same process as the one that is
failing.
Just got off the phone with Microsoft Tech Support. It turns out that the
entire problem was the FileSequenceStart value in the ImageFamiles table.
Although the SDK docs say that you can use a NULL value when using MSI 2.0
(or higher, I suppose), that ain't quite true. In my case, I had to put in
a value.
I first used a very high number - higher than the total number of files
installed. That caused a different error. Then I used a value of 3 (MS
recommended a value higher than 2 - don't know why). That appears to have
solved my problem.
Jason
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:%23VjEIgK...@TK2MSFTNGP14.phx.gbl...
Carolyn Napier [MSFT]
can still use NULL for those values in the PCP file. There's just one case
where this doesn't work right and it's the one you hit (which is why there's an
update in the next release of patchwiz to address it):
By default if you don't set FileSequenceStart, PatchWiz starts with a value of
2. PatchWiz is also responsible for keeping track of the running total of files
in the patch cabinet and the order. You see this problem if you have a
full-file update for the file and the sequence number that patchwiz assigned for
the file in the patch cabinet is the same as the sequence number of the file in
the upgraded image package.
This causes the Installer to fail to detect that the file was updated by the
patch because the transforms embedded within the MSP don't have the right data.
There's an easy repro scenario to demonstrate:
(-) Start with a base package with a file, say red.exe, that has sequence
number 1
(-) In the update package, don't change red.exe but instead add a new file,
blue.exe, that has sequence number 2
(-) Build your MSP off of the PCP with the FileSequenceStart left blank
(-) Apply the patch -- see the failure reported here
What basically happens is that patchwiz starts with a sequence starting point of
2 when FileSequenceStart is NULL. The file blue.exe is newly added and
therefore will be a full-file update. The sequence # patchwiz assigns to the
file in the cabinet starts with the starting number since this is the first
different file (recall that red.exe was unchanged). So, patchwiz assigns it a
sequence # of 2. This is the same value that was used for the sequence number in
the update package.
Hence, the Installer doesn't detect that this file was updated because it
doesn't see the difference.
In any case, you can work-around it by assigning a FileSequenceStart number.
- Carolyn Napier
Microsoft Windows Installer Team
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.
MSI FAQ:
<http://www.microsoft.com/windows2000/community/centers/management/msi_faq.mspx>
"Jason Swager" <jason-...@activevoice.remove-me.com> wrote in message
news:uPsZWFL...@TK2MSFTNGP09.phx.gbl...
Michael
available?
Thanks,
Michael
Jason Swager
another new issue with Microsoft Tech Support. The workaround from the
first support ticket isn't working - and they're having some problem getting
the new ticket created.
Anyway, the original workaround of using FileSequenceStart greater than 2 no
longer works. Consequently, all patches now fail.
Jason
"Michael" <m.hlavi...@bre.com> wrote in message
news:91749A1A-04E5-4718...@microsoft.com...
Michael
files you do. So far that seems to work for me. Good luck.
Michael