February 2014 - Wine-devel - list.winehq.org

Re: [2/2] taskschd: Add IRegisteredTaskCollection stub implementation.
by Alexandre Julliard 04 Feb '14

04 Feb '14

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > --- > dlls/taskschd/Makefile.in | 1 + > dlls/taskschd/folder.c | 9 ++- > dlls/taskschd/regtask_collection.c | 161 +++++++++++++++++++++++++++++++++++++ > dlls/taskschd/taskschd_private.h | 1 + > 4 files changed, 170 insertions(+), 2 deletions(-) > create mode 100644 dlls/taskschd/regtask_collection.c > > diff --git a/dlls/taskschd/Makefile.in b/dlls/taskschd/Makefile.in > index a1835fc..c85da9b 100644 > --- a/dlls/taskschd/Makefile.in > +++ b/dlls/taskschd/Makefile.in > @@ -5,6 +5,7 @@ C_SRCS = \ > folder.c \ > folder_collection.c \ > regtask.c \ > + regtask_collection.c \ Please try to group related interfaces into the same source file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: add CM_Get_Device_Interface_List_Size(A/W) stubs (1/2)
by Dmitry Timoshkov 04 Feb '14

04 Feb '14

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall CM_Get_Device_Interface_List_SizeA(ptr str ptr long) > +@ stdcall CM_Get_Device_Interface_List_SizeW(ptr wstr ptr long) These entries are completely wrong. Same goes for 2/2. -- Dmitry.

1 0

Re: [2/2] bcrypt/tests: Add tests for BCryptGenRandom
by Bruno Jesus 03 Feb '14

03 Feb '14

Please, ignore this patch. It will fail the tests since wine will load the stubbed function and crash. I thought it would fail to load the function in GetProcAddress. On Mon, Feb 3, 2014 at 3:51 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > -- universe* god::bigbang (void); //and then it all began...

1 0

RFC - bcrypt: Semi-stub BCryptGenRandom
by Bruno Jesus 03 Feb '14

03 Feb '14

Hi, I'm looking for comments related to the attached patch. Is it valid to use advpi32? It seems to be the most easy way to generate random numbers. If not valid, what other ways are there to generate random numbers? If anyone would like to compile this patch please also get http://source.winehq.org/patches/data/102143 Thanks in advance, Bruno

2 1

Re: Assorted typos fixes
by Marvin 02 Feb '14

02 Feb '14

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=4563 Your paranoid android. === wxppro (32 bit device) === device.c:107: Test failed: GetDeviceData() failed: 00000000

1 0

dpnet patches
by Stefan Dösinger 01 Feb '14

01 Feb '14

Hi Alistair, A while ago I promised to have a closer look at your dpnet patches. It’s a bit delayed, but here are some comments. How serious are you about dplay? Do you intend to do more work towards implementing it, or is that just wishful thinking on my part? http://source.winehq.org/patches/data/101857: The entire patch doesn’t do all that much, I think it’s best to hold of on that change until the function is meaningfully implemented - unless having a proper return value helps you in some way I’m missing. > + void *buffer = malloc(256); Please use HeapAlloc / HeapFree. http://source.winehq.org/patches/data/101856: > +DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); Isn’t that defined somewhere already? Do you need GUID_NULL to signal an uninitialized GUID? Is there a reason why setting the pointer to NULL doesn’t work? > -IMPORTS = dpnet ole32 > +IMPORTS = ole32 I’m not sure about this one, but winetest can automatically skip tests if the tested DLL doesn’t exist. It might use the imported libraries for that, or maybe just the name of the test. In the former case I think you want to keep the dpnet import. http://source.winehq.org/patches/data/101855: http://source.winehq.org/patches/data/101854: Did you think about sharing code between IDirectPlay8Peer and IDirectPlay8Server? The interfaces themselves have no relationship, but their methods are similar. http://source.winehq.org/patches/data/101853: > +typedef struct IDirectPlay8ClientImpl > +{ > + IDirectPlay8Client IDirectPlay8Client_iface; > + LONG ref; > +} IDirectPlay8ClientImpl; Are you sure you want to move the definition out of the library-wide header? If that works out ok it’s great, but you may need something other than the public interface in some other files in this library. I recommend to work without the typedef, but that should be changed in a separate patch. > - ULONG refCount = InterlockedIncrement(&This->ref); > + ULONG ref = InterlockedIncrement(&This->ref); > - TRACE("(%p)->(ref before=%u)\n", This, refCount - 1); > + TRACE("(%p) ref=%d\n", This, ref); ULONG is unsigned, you have to use %u. http://source.winehq.org/patches/data/101852 > + 'DPNSPModemModem' > + { > + val 'Friendly Name' = s 'Modem Connection For DirectPlay' > + val 'GUID' = s '{6D4A3650-628D-11D2-AE0F-006097B01411}' > + } > + > + 'DPNSPModemSerial' > + { > + val 'Friendly Name' = s 'Serial Connection For DirectPlay' > + val 'GUID' = s '{743B5D60-628D-11D2-AE0F-006097B01411}' > + } I know that those always exist on Windows, but wouldn’t it be better to not advertise them until we have an actual implementation? I think advertising DPNSPWinsockTCP alone should be ok for the start.

2 1

Re: [PATCH v7 1/7] VFS: Introduce new O_DENY* open flags
by Jeff Layton 01 Feb '14

01 Feb '14

On Fri, 17 Jan 2014 18:18:47 +0000 One Thousand Gnomes <gnomes(a)lxorguk.ukuu.org.uk> wrote: > > +#define ESHAREDENIED 258 /* File is locked with a sharelock */ > > Have you prepared C library patches to match this ? > > (and why not just use EPERM, it has the meaning you want already) > Tough call... On the one hand, ESHAREDENIED is a distinct error code so an application has the ability to determine what happened when an open or unlink fails. OTOH, a lot of applications won't understand ESHAREDENIED and may barf on it. Those apps might handle EPERM better. I'm not sure what the right approach is there... > > > + * 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) ? > > Agreed. This needs a mechanism that allows you to override it, IMO. CAP_DAC_OVERRIDE doesn't seem quite like the right thing since this isn't dealing with permissions, per-se. A new capability bit may even be warranted. > > + > > + /* > > + * 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 ? > > > > > 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 -- Jeff Layton <jlayton(a)redhat.com>

1 0