January 2014 - Wine-Devel - list.winehq.org

Re: msxml3: Don't return implementation pointer as an interface.
by Nikolay Sivov Jan. 20, 2014

Jan. 20, 2014

On 1/21/2014 09:08, Dmitry Timoshkov wrote: > --- > dlls/msxml3/xmlelem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/msxml3/xmlelem.c b/dlls/msxml3/xmlelem.c > index 2130c713..c525c8b 100644 > --- a/dlls/msxml3/xmlelem.c > +++ b/dlls/msxml3/xmlelem.c > @@ -663,7 +663,7 @@ static HRESULT WINAPI xmlelem_collection_get__newEnum(IXMLElementCollection *ifa > if (!ppUnk) > return E_INVALIDARG; > > - *ppUnk = (IUnknown *)This; > + *ppUnk = (IUnknown *)&This->IXMLElementCollection_iface; > IUnknown_AddRef(*ppUnk); > return S_OK; > } It's not necessary wrong, but it's possible it returns IEnumVARIANT here, it's easy to test.

1 0

Re: [website] Portuguese translation for release 1.7.10
by Bruno Jesus Jan. 20, 2014

Jan. 20, 2014

2014/1/20 Lucas Zawacki <lfzawacki(a)gmail.com>: > + <li>Extensão do suporte ao protocolo IPX.</li> Should be "Suporte ao protocolo IPX estendido". Regards, Bruno

1 0

Re: [PATCH v7 1/7] VFS: Introduce new O_DENY* open flags
by Pavel Shilovsky Jan. 20, 2014

Jan. 20, 2014

2014/1/17 One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk>: >> +#define ESHAREDENIED 258 /* File is locked with a sharelock */ > > Have you prepared C library patches to match this ? I don't have it for now. > > (and why not just use EPERM, it has the meaning you want already) We need to determine if we have a share reservation error to map it accurately in file servers and wine. > > >> + * Check to see if there's a share_reservation conflict. LOCK_READ/LOCK_WRITE >> + * tell us whether the reservation allows other readers and writers. >> + */ >> +static int >> +locks_mand_conflict(struct file_lock *caller_fl, struct file_lock *sys_fl) >> +{ > > Shouldn't this also check for CAP_SYS_DAC or some similar permission so > that root can override such a mess (eg to fix full disks in an > emergency) ? May be it's better to let root an ability to remount the system without sharelock mount option and then fix an emergency? > > >> + >> + /* >> + * For sharelock mounts if a file was created but not opened, we need >> + * to keep parent i_mutex until we finish the open to prevent races when >> + * somebody opens newly created by us file and locks it with a sharelock >> + * before we open it. >> + */ >> + if (IS_SHARELOCK(dir->d_inode) && error > 0 && *opened & FILE_CREATED) { >> + /* Don't check for write permission, don't truncate */ >> + open_flag &= ~O_TRUNC; >> + will_truncate = false; >> + acc_mode = MAY_OPEN; >> + path_to_nameidata(path, nd); >> + >> + error = may_open(&nd->path, acc_mode, open_flag); >> + if (error) { >> + mutex_unlock(&dir->d_inode->i_mutex); >> + goto out; >> + } >> + file->f_path.mnt = nd->path.mnt; >> + error = finish_open(file, nd->path.dentry, NULL, opened); >> + if (error) { >> + mutex_unlock(&dir->d_inode->i_mutex); >> + if (error == -EOPENSTALE) >> + goto stale_open; >> + goto out; >> + } >> + error = sharelock_lock_file(file); >> + mutex_unlock(&dir->d_inode->i_mutex); >> + if (error) >> + goto exit_fput; >> + goto opened; >> + } >> + >> mutex_unlock(&dir->d_inode->i_mutex); > > What stops the file system changing mount flags via a remount between > these two ? Nothing, but it doesn't bring problems here: if the first IS_SHARELOCK condition is true, we don't get into the second (see 'goto opened'). > >> >> if (error <= 0) { >> @@ -3034,6 +3073,18 @@ finish_open_created: >> goto stale_open; >> goto out; >> } >> + >> + if (IS_SHARELOCK(dir->d_inode)) { >> + /* >> + * Lock parent i_mutex to prevent races with sharelocks on >> + * newly created files. >> + */ >> + mutex_lock(&dir->d_inode->i_mutex); >> + error = sharelock_lock_file(file); >> + mutex_unlock(&dir->d_inode->i_mutex); >> + if (error) >> + goto exit_fput; >> + } >> opened: > -- > To unsubscribe from this list: send the line "unsubscribe linux-cifs" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards, Pavel Shilovsky.

1 0

Re: [PATCH] oleaut32: Improve ITypeLib::FindName
by Nikolay Sivov Jan. 20, 2014

Jan. 20, 2014

On 1/17/2014 21:40, Andrew Eikum wrote: > --- > dlls/oleaut32/tests/typelib.c | 99 +++++++++++++++++++++++++++++++++++++++++-- > dlls/oleaut32/typelib.c | 19 ++++++--- > 2 files changed, 107 insertions(+), 11 deletions(-) > + > for(fdc = 0; fdc < pTInfo->cFuncs; ++fdc) { > TLBFuncDesc *func = &pTInfo->funcdescs[fdc]; > int pc; > > - if(!TLB_str_memcmp(name, func->Name, len)) goto ITypeLib2_fnFindName_exit; > - for(pc = 0; pc < func->funcdesc.cParams; pc++) { > - if(!TLB_str_memcmp(name, func->pParamDesc[pc].Name, len)) > - goto ITypeLib2_fnFindName_exit; > + if(!TLB_str_memcmp(name, func->Name, len)) { > + memid[count] = func->funcdesc.memid; > + goto ITypeLib2_fnFindName_exit; > } > } > Minor problem, 'pc' should be removed.

1 0

Re: [PATCH] widl: Fix pointer size for SYS_WIN64 typelibs (try2)
by Marvin Jan. 19, 2014

Jan. 19, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4361 Your paranoid android. === w2008s64 (64 bit typelib) === typelib.c:3925: Test failed: typeattr->cbSizeInstance expected 8 got 4 typelib.c:3925: Test failed: typeattr->cbSizeInstance expected 8 got 4 === w7pro64 (64 bit typelib) === typelib.c:3925: Test failed: typeattr->cbSizeInstance expected 8 got 4 typelib.c:3925: Test failed: typeattr->cbSizeInstance expected 8 got 4

2 1

Re: ws2_32/tests: Add missing closesocket calls (Coverity)
by Marvin Jan. 18, 2014

Jan. 18, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4360 Your paranoid android. === wxppro (32 bit sock) === sock.c:557: Test failed: oob_server (22c): unexpectedly at the OOB mark: 0 === w2008s64 (32 bit sock) === sock.c:557: Test failed: oob_server (768): unexpectedly at the OOB mark: 0 sock: unhandled exception c0000005 at 00000000 === w2008s64 (64 bit sock) === sock.c:557: Test failed: oob_server (750): unexpectedly at the OOB mark: 0

1 0

Re: [28/28] xmllite/tests: Use common wine_dbgstr_guid implementation from test.h
by Marvin Jan. 17, 2014

Jan. 17, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4340 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [27/28] windowscodecs/tests: Use common wine_dbgstr_guid implementation from test.h
by Marvin Jan. 17, 2014

Jan. 17, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4339 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [26/28] vbscript/tests: Use common wine_dbgstr_guid implementation from test.h
by Marvin Jan. 17, 2014

Jan. 17, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4338 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [25/28] urlmon/tests: Use common wine_dbgstr_guid implementation from test.h
by Marvin Jan. 17, 2014

Jan. 17, 2014

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=4337 Your paranoid android. === build (build) === Patch failed to apply

1 0