Attached is a patch that fixes the truncation of the property values
returned by msilib.SummaryInfo.GetProperty(). Unfortunately Microsoft
has deemed it necessary to return the size of the string without the
null termination character but insists upon the size including it when
passing it in. Arggh!

The patch looks correct, it's now a matter of unit tests.
for example, I'd test the case where the length is around 1000..

I have updated the patch for current trunk (though no real changes required). I also include a testcase.

One thing to review is that I added functionality to the tests to create the MSI to be tested. (felt this was safer than touching one of the ones under %systemroot%\installer.

+ path, msilib.schema, "Ptyhon Tests", "product_code", "1.0", "PSF")
s/Ptyhon/Python/

And fix the typo... (thanks Ezio)

This patch seems okay to me, as far as it goes. I'd like to hear Martin's feedback, but I think it should be committed.

And I realize the rest of this message doesn't apply to the patch, but it does address other problems in summary_getproperty(). At least one of these led to the original problem with the truncated character.

1. It's not clear to me that the malloc() call only occurs if the type is VT_LPSTR. But that's the only case where free() is called. I think it would be better to move the call to free() to a cleanup section at the end of the function.

2. The status is never checked for success, just for one specific failure. I think both calls to MsiSummaryInfoGetProperty should be looking for ERROR_SUCCESS.

3. I don't think VT_FILETIME is special enough for its own error message. It should just be caught with all other unknown types.

Maybe these last 3 should get their own new issue.

Responding to Eric's comments

1. There are only three valid property types returned by MsiInteger, String & FILETIME. (http://msdn.microsoft.com/en-us/library/aa372045%28v=VS.85%29.aspx)

2. That comment makes sense - I have entered a new issue (bpo-12202) for that.

3. Per 1. - there shouldn't be any other unhandled types. I have entered issue bpo-12201 to track adding support for FILETIMEs.

Despite the fact that as of now (or 6+ years ago!) the only way to trigger the malloc() is via VT_LPSTR, I still think the way the free() call is written is bad. What if another type is added?

If that were fixed, I still think the basic idea of this patch in isolation of the other raised issues is a good idea. If it was converted to a PR, I'd support merging it (although I'd like to hear from the Windows folks).

But it is curious that this bug is so old and it hasn't caused more problems.

I have created a PR bpo-4517 from the patch. Would it be better to track the malloc problem in a new issue?

As for why this never caused any problems… msilib is pretty standalone, and not one of the most used modules. It is also pretty trivial to roll your own solution with ctypes (or any FFI library), which is what I did when I hit this bug.

I made a shot to address the free() call. Hopefully this makes sense.

I resolved some conflicts and will merge this once CI completes.

If the backport to 2.7 isn't automatic then it may wait until someone else comes in to do it.

New changeset 2de576e by Steve Dower (Tzu-ping Chung) in branch 'master':
bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517)
2de576e

As expected, the 2.7 backport needs more work.

Leaving this open for anyone who wants to handle it. I'll happily click merge for you if CI passes.

New changeset 56f8411 by Miss Islington (bot) in branch '3.7':
bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517)
56f8411

New changeset d5409eb by Miss Islington (bot) (Tzu-ping Chung) in branch '2.7':
[2.7] bpo-1104: msilib.SummaryInfo.GetProperty() truncates the string by one character (GH-4517) (GH-11749)
d5409eb