[PATCH v2 4/5] ole32: Reset CLSID of datacache so that automatic entry is re-created on load.
Huw Davies
huw at codeweavers.com
Wed Apr 4 02:57:15 CDT 2018
On Tue, Apr 03, 2018 at 06:13:09PM -0500, Sergio Gómez Del Real wrote:
> 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?
Ok, I see, thanks. Could you move it to above the blank line above
ReadClassStg(), so it sits in the 'destruction of cache entries block'?
Thanks,
Huw.
More information about the wine-devel
mailing list