http://bugs.winehq.org/show_bug.cgi?id=11759
--- Comment #25 from Anastasius Focht focht@gmx.net 2008-08-05 16:34:41 --- Created an attachment (id=15304) --> (http://bugs.winehq.org/attachment.cgi?id=15304) +tid,+seh,+msi,+msidb trace
Hello,
attached is relevant msi trace. That file(s) in question resides in msi patch db (silverlight.msp) and is not temporarily extracted at the time, hence the copy fails.
There is also a bug in MsiConfigureProductExW() which sometimes leads to premature failures.
--- snip dlls/msi/msi.c --- UINT WINAPI MsiConfigureProductExW(LPCWSTR szProduct, int iInstallLevel, INSTALLSTATE eInstallState, LPCWSTR szCommandLine) { MSIPACKAGE* package = NULL; MSIINSTALLCONTEXT context; UINT r; DWORD sz; WCHAR sourcepath[MAX_PATH]; WCHAR filename[MAX_PATH]; .. sz = sizeof(sourcepath); memset( sourcepath, 0, sz); MsiSourceListGetInfoW(szProduct, NULL, context, MSICODE_PRODUCT, INSTALLPROPERTY_LASTUSEDSOURCEW, sourcepath, &sz);
sz = sizeof(filename); memset( filename, 0, sz); MsiSourceListGetInfoW(szProduct, NULL, context, MSICODE_PRODUCT, INSTALLPROPERTY_PACKAGENAMEW, filename, &sz);
lstrcatW(sourcepath, filename); r = MSI_OpenPackageW(sourcepath, &package); .. } --- snip dlls/msi/msi.c ---
If MsiSourceListGetInfoW() calls fail for some reason and don't fill out/return buffer (see fixme:msi:MsiSourceListGetInfoW Unhandled context 4), you might end up copying garbage because the buffer is allocated on stack and not explicitly initialized.
Regards