I can’t find any definition with a reference to the length, what I did find is
ICE29
(http://msdn.microsoft.com/en-us/library/windows/desktop/aa368953(v=vs.85).aspx)
; “Handling of streams by the Win32 OLE structured storage implementation
limits stream names. See OLE Limitations on Streams. The installer can compress
stream names up to 62 characters in length. Names longer than this are
truncated.”
This to me hints that something is supposed to be truncating the stream
identifiers. I tested an insert via VBScript instead of a direct table import,
and it fails as well.
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: Wednesday, July 10, 2013 12:09 PM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] SFBUG: 3341/3340
I understand that, we have other cases where we check against 40 chars for like
Binary elements. The question is our table definition incorrect compared to the
standard Windows Installer schema?
We should definitely have appropriate internal checks to handle the 40 chars
even if the schema is "wrong" (right by MSI, wrong by reality).
On Wed, Jul 10, 2013 at 10:05 AM, Hoover, Jacob
<jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>> wrote:
Yes, the MsiDigitalCertificate table has the DigitalCertificate field defined
as an identifier (s72), but because the certificate is in this temporary
_Streams table which has a max length of 72 then the true max length of the
DigitalCertificate field is 40.
Here is an older reference to the same problem with a different tool:
http://makemsi-manual.dennisbareis.com/a_windows_installer_streams_table_key_longer_than_62_bytes_corrupts_the_database.htm
You can try it yourself with orca, it’s impossible to insert a record into the
MsiDigitalCertificate table with a DigitalCertificate value having a length
greater than 40.
From: Rob Mensching [mailto:r...@robmensching.com<mailto:r...@robmensching.com>]
Sent: Wednesday, July 10, 2013 11:44 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] SFBUG: 3341/3340
1. Not sure what error message you are referring to but if you can help improve
it that would be awesome. Better error messages are always welcome.
2. The column definitions come from the Windows Installer team. Are you saying
they said a column width is 40 in a table but we put 72? If so that would be a
bug. If the other way around, that would be their bug that we need to follow so
that our table definitions are consistent with the rest of the world
(especially important for those shipping Merge Modules).
On Wed, Jul 10, 2013 at 9:39 AM, Hoover, Jacob
<jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>> wrote:
Argh! (Delete long running ramblings of the 400 things I tried…)
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372919(v=vs.85).aspx
The certificates are “stored” in the temporary _Streams table, which has a
definition for Name as a max length of 62 characters. When MsiDatabaseImport
is importing the certificates, it uses the notation of TableName.Identifier for
the stream. So, the max length for an identifier on the MsiDigitalCertificate
table is 40, not 72. (Sure would be nice if we had a meaningful error message
for this. I wonder why we don’t set the length of the column to the right
value.)
From: Rob Mensching [mailto:r...@robmensching.com<mailto:r...@robmensching.com>]
Sent: Wednesday, July 10, 2013 9:38 AM
To: Windows Installer XML toolset developer mailing list
Subject: Re: [WiX-devs] SFBUG: 3341/3340
Re: ::MsiDatabaseImport()
It is a bit of a pain to debug when there are failures however:
1. MsiDatabaseImport is a couple orders of magnitude faster to create the MSI
over using the SQL queries.
2. MsiDatabaseImport creates the smallest MSI files. The SQL insert/update
queries can add "hot air" to an MSI so we want to minimize their use to what is
absolutely necessary.
On Tue, Jul 9, 2013 at 10:57 AM, Hoover, Jacob
<jacob.hoo...@greenheck.com<mailto:jacob.hoo...@greenheck.com>> wrote:
When looking at SFBUG 3340 and 3341, I attempted to prefix the identifier.
Any time I use anything other than the hash it fails to import. I’ve tried
multiple variations (_, cer, Z, etc) of a prefix. Each time I have verified
that the certificate name in the IDT matches that of the file on disk in the
MsiDigitalCertificate sub folder. I’ve tried it with only changing the
identifier and with changing both the identifier and the file name.
By chance is there something mis-documented on either the table definition or
the MsiDatabaseImport function? (Is there a reason we are using this instead of
using the DB functions directly?)
It may be worth mentioning that I can’t even adjust this value with Orca. It
fails on commit with “The data was rejected by the database. It may be out of
the valid range or formatted incorrectly”. I can modify the identifier in the
MsiDigitalSignature table, and I can modify another record in the
MsiDigitalCertificate table. (I have a local fix that leaves the named key from
the MsiPatchCertificate table in place.) The only other unique thing I can
think of is both certs are identical.
Thanks,
Jacob
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
