msi:RECORD_StreamFromFile bug, help needed

[robert.van.herk at serioustoys.com]

Dear Hans and dear group,

Thanks for your input!
I altered my local source tree, such that it opens the file exclusively as a stream. That seems to work.

Having that fixed, at least provisionally, I am now facing another issue: my MSIs are most of the time very small, only about 5 megs. This is wrong. In some runs, it goes fine though, and they reach 300 megs, which is the right size.
I find no error messages in the +relay trace... The process seems to be completely unpredictable.

I can see in my Windows temp dir that the temporary files created there do seem to  add up to about 300 megs, but then when the final MSI is baked, something seems to go wrong... (?)

Would you have any idea of how this could be?
Maybe some race-condition?

It seems to be unrelated to the other bug (the one described before: GlobalAllocing a big block to copy file contents into), because before this fix this current behaviour also happened in the instances where the GlobalAlloc didn't fail.

Any help would be appreciated!

Kind regards,
Robert
________________________________________
Van: Hans Leidekker [hans at codeweavers.com]
Verzonden: dinsdag 19 juni 2012 9:29
Aan: robert.van.herk at serioustoys.com
CC: wine-devel at winehq.org
Onderwerp: Re: msi:RECORD_StreamFromFile bug, help needed

On Mon, 2012-06-18 at 14:14 +0200, robert.van.herk at serioustoys.com wrote:

> But then I was thinking: this seems like such an obvious thing to do, that it is
> almost suspicious. Was there any reason for copying the file contents to main
> memory and then create a memory stream?
>
> For instance, was the intention to have a non-mutable copy in memory, in case
> the backing file would be altered later on?

Yes, the concern is that the file could be changed or removed. We should
test what native does here but it probably means that we need to create a stream
on the file with a sharing mode that denies writing.

> I guess if that's the case, I could just create a copy of the original file in
> a temp dir, and mark it as STGM_DELETEONRELEASE.

It would take a long time to copy such a large file.