[PATCH v2 4/5] ole32: Reset CLSID of datacache so that automatic entry is re-created on load.

Sergio Gómez Del Real sdelreal at codeweavers.com
Tue Apr 3 18:13:09 CDT 2018


On 03/04/18 05:12, Huw Davies wrote:

> On Fri, Mar 30, 2018 at 12:11:36PM -0500, Sergio Gómez Del Real wrote:
>> Signed-off-by: Sergio Gómez Del Real <sdelreal at codeweavers.com>
>> ---
>>   dlls/ole32/datacache.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/dlls/ole32/datacache.c b/dlls/ole32/datacache.c
>> index 0f23faf08c..452e171e4c 100644
>> --- a/dlls/ole32/datacache.c
>> +++ b/dlls/ole32/datacache.c
>> @@ -1862,6 +1862,7 @@ static HRESULT WINAPI DataCache_Load( IPersistStorage *iface, IStorage *stg )
>>           DataCacheEntry_Destroy( This, entry );
>>   
>>       ReadClassStg( stg, &clsid );
>> +    This->clsid = CLSID_NULL;
> This is probably hiding another bug.  In the new tests you add in
> [5/5] the cache entries should have been created when the cache is
> created.  Could you investigate what's going on?
>
> Huw.

In create_automatic_entry() we have:/
/

    /if (IsEqualCLSID( &cache->clsid, clsid )) return S_OK;/

which I guess is there to prevent creating 2 static entries of the same 
CF. When data cache is created with a static picture, its clsid is set 
with one of CLSID_Picture_*, but only after calling 
create_automatic_entry(). Then, in _Load, the data cache is flushed (its 
entries destroyed), but its clsid isn't cleared; it maintains one of 
CLSID_Picture_* values. The patch does this clearance, which I think 
makes sense (since we are loading new entries and clsid from a storage), 
and so when create_automatic_entry() is called right after destroying 
the entries and reading the storage's clsid, it will succeed.

I would think that it is correct to 'reset' the clsid in _Load, as done 
in this patch, right after destroying the entries and before reading in 
the new entries and clsid from the storage; and also that 
create_automatic_entry() is correct to check the CLSIDs so as to avoid 
creating a new entry, which wouldn't be the desired behavior. What do 
you think?

- Sergio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20180403/89b0f0a1/attachment.html>


More information about the wine-devel mailing list