July 2013 - Wine-Devel - list.winehq.org

Re: readme: Update German translation

by Joerg Schiermeier

> Hi ... list, Hi Julian > I think "liesmich" is more common than "lesmich", although both sound > awkward. Do we need/want to translate that? Yes really. 'Liesmich' is a direct translation of 'readme'. Eventually this older translation was a simply typo? So please change this! Thanks. > Best, > Julian -- Kindly regards Joerg Schiermeier Bielefeld/Germany

July 9, 2013

Re: readme: Update German translation

by André Hentschel

On 09.07.2013 20:52, Alexandre Julliard wrote: > Julian Rüger <jr98(a)gmx.net> writes: > >> PS: I have some more manpage-patches in the works, but my spare time has >> been a little scarce lately. Do you think 1.6 will be released Friday? > > No, there will be an rc5 this Friday. There's a good chance that it will > be the last rc though. > Even if you don't make it in time for 1.6, there's still time to get it into e.g. 1.6.1

July 9, 2013

Re: readme: Update German translation

by Alexandre Julliard

Julian Rüger <jr98(a)gmx.net> writes: > PS: I have some more manpage-patches in the works, but my spare time has > been a little scarce lately. Do you think 1.6 will be released Friday? No, there will be an rc5 this Friday. There's a good chance that it will be the last rc though. -- Alexandre Julliard julliard(a)winehq.org

July 9, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Nikolay Sivov

On 7/9/2013 18:52, Qian Hong wrote: > Hi Nikolay, > > Thanks for comments! > > On Tue, Jul 9, 2013 at 9:01 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> Do you really need this for Office 2010 or null check is enough? If it's >> passing 0 handle here that's what you should check imho. If HIMCC is really >> a handle and not a struct pointer like in wine, that's not how a handle >> validity check will look like. > null check is not enough, see the below quoted log: > --- snip --- > 0029:Call imm32.ImmGetIMCCSize(bf9c73e5) ret=0d6d3545 > --- snip --- This could be some a different bug, and putting exception handler around it is not necessary a right solution. > > Another example: > --- snip --- > 0029:Call imm32.ImmGetIMCCSize(00000190) ret=0a193545 > --- snip --- > > Could you provide more details for how to check the validity of the > handle in the right way? Well, if it's really supposed to be a handle, meaning it's a table index (with some offset or not), this check will simply check for index boundaries and whether slot is allocated. This all need some tests. > > Thanks a lot! > > > -- > Regards, > Qian Hong > > - > http://www.winehq.org >

July 9, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Qian Hong

Hi Nikolay, Thanks for comments! On Tue, Jul 9, 2013 at 9:01 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Do you really need this for Office 2010 or null check is enough? If it's > passing 0 handle here that's what you should check imho. If HIMCC is really > a handle and not a struct pointer like in wine, that's not how a handle > validity check will look like. null check is not enough, see the below quoted log: --- snip --- 0029:Call imm32.ImmGetIMCCSize(bf9c73e5) ret=0d6d3545 --- snip --- Another example: --- snip --- 0029:Call imm32.ImmGetIMCCSize(00000190) ret=0a193545 --- snip --- Could you provide more details for how to check the validity of the handle in the right way? Thanks a lot! -- Regards, Qian Hong - http://www.winehq.org

July 9, 2013

Re: [PATCH] imm32: Fixed crashing in ImmGetIMCCSize.

by Nikolay Sivov

On 7/9/2013 16:50, Qian Hong wrote: > Fixed a crash in MS Office 2010 Chinese version. > Thanks Jiang Yike for the helps on testing :) > > --- > dlls/imm32/imm.c | 6 ++++++ > dlls/imm32/tests/imm32.c | 13 +++++++++++++ > 2 files changed, 19 insertions(+) > > > > > + if (IsBadReadPtr(internal, sizeof(HIMCC))) > + { > + SetLastError(ERROR_INVALID_HANDLE); > + return 0; > + } > + Do you really need this for Office 2010 or null check is enough? If it's passing 0 handle here that's what you should check imho. If HIMCC is really a handle and not a struct pointer like in wine, that's not how a handle validity check will look like.

July 9, 2013

Re: Should we translate the prompt

by Jactry Zeng

Thanks Francois! I will renew the Simplified Chinese translation in the next patch. 2013/7/8 Francois Gouget <fgouget(a)free.fr> > On Sun, 7 Jul 2013, Jactry Zeng wrote: > [...] > > msgid "%1? (Yes|No)\n" > [...] > > When I discuss this with Qian Hong, he give a better idea. We may can > just > > make the origin text more apropos, just like: > > msgid "%1? (Y)es|(N)o\n" > > I think this would look odd in English and that the original string is > better. > > > > So that we can translate it into Simplified Chinese: > > msgid "%1？是(Y)|否(N)¥n" > > I think this translation would be ok, even for the original string. I > see it as similar to the recommendation of following translated menu > labels with with the original English hotkey in parentheses. > > We have very few places where we have this situation. As far as I > know there is this message, the '(Yes|No|All)' version, and the > following one: > > msgid "" > "Is '%1' a filename or directory¥n" > "on the target?¥n" > "(F - File, D - Directory)¥n" > > > Also, whichever way we go, I think it could apply equally well to > the Traditional Chinese, Japanese and Korean translations too. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > The software said it requires Win95 or better, so I installed Linux. -- Regards, Jactry Zeng

July 9, 2013

Re: readme: Update German translation

by Julian Rüger

Am Dienstag, den 09.07.2013, 00:46 +0200 schrieb André Hentschel: > --- > documentation/README.de | 14 ++++---------- > 1 file changed, 4 insertions(+), 10 deletions(-) > Hi André and list, patch looks good to me. One minor remark: > + wine notepad.exe lesmich.txt (Programmaufruf mit Parametern) I think "liesmich" is more common than "lesmich", although both sound awkward. Do we need/want to translate that? Best, Julian PS: I have some more manpage-patches in the works, but my spare time has been a little scarce lately. Do you think 1.6 will be released Friday?

July 9, 2013

Re: po: Arabic full translated wine. (try2)

by Francois Gouget

On Mon, 1 Jul 2013, Yaron Shahrabani wrote: > Non critical changes but take a look if you like: > #: comdlg32.rc:186 comdlg32.rc:141 > -#, fuzzy > msgid "Save As" > msgstr "احفظ &ك‍..." > > Redundant Ellipsis. You can find a list of issues of this type there: http://fgouget.free.fr/wine-po/ar.check.html The URL below also has a list of potential spelling issues but given their number I wonder if aspell's dictionary is really up to the task: http://fgouget.free.fr/wine-po/ar.spell.html In both cases I would really appreciate if you could have a look, fix what can be fixed and let me know about false positives so I can cull the list. One last point, I noticed that you also translated the messages for the command line tools. Do they look ok in the GNOME terminal and other similar tools? The issue came up for Wine 1.4 and at the time terminal emulators where unable to deal with right-to-left languages which is why I'm asking. In the end for Hebrew it was decided to not translate the command line messages so users would have something usable. References: * RTL in console windows http://www.winehq.org/pipermail/wine-devel/2010-October/087325.html * Hebrew: update http://www.winehq.org/pipermail/wine-devel/2011-August/091672.html http://www.winehq.org/pipermail/wine-devel/2011-August/091771.html -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

July 8, 2013

Re: Should we translate the prompt

by Francois Gouget

On Sun, 7 Jul 2013, Jactry Zeng wrote: [...] > msgid "%1? (Yes|No)\n" [...] > When I discuss this with Qian Hong, he give a better idea. We may can just > make the origin text more apropos, just like: > msgid "%1? (Y)es|(N)o\n" I think this would look odd in English and that the original string is better. > So that we can translate it into Simplified Chinese: > msgid "%1？是(Y)|否(N)¥n" I think this translation would be ok, even for the original string. I see it as similar to the recommendation of following translated menu labels with with the original English hotkey in parentheses. We have very few places where we have this situation. As far as I know there is this message, the '(Yes|No|All)' version, and the following one: msgid "" "Is '%1' a filename or directory¥n" "on the target?¥n" "(F - File, D - Directory)¥n" Also, whichever way we go, I think it could apply equally well to the Traditional Chinese, Japanese and Korean translations too. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

July 8, 2013

Should we translate the prompt

by Jactry Zeng

Hi everybody, In po file there were some prompts as this: #: xcopy.rc:35 msgid "%1? (Yes|No)\n" I am not sure that should I translate them in po file for Simplified Chinese. But they have been translated in po file for French and Traditional Chinese. As prompts in command line, I don't think translating them into another language is good. It may make the users don't know what should them type into. When I discuss this with Qian Hong, he give a better idea. We may can just make the origin text more apropos, just like: msgid "%1? (Y)es|(N)o\n" So that we can translate it into Simplified Chinese: msgid "%1？是(Y)|否(N)\n" Thanks for any comment. -- Regards, Jactry Zeng

July 7, 2013

Re: [PATCH] gdiplus: fixing identical sub-expressions

by Vincent Povirk

I'm not sure we should change this during code freeze.

July 7, 2013

Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-07-01 20:08-0700 Austin English wrote: > In other words, while fixing Cygwin issues is a valuable effort, it > takes a lot of time and effort that is better spent elsewhere. Hi Austin: I agree that fixing Cygwin on Wine issues will take some considerable initial effort learning about Cygwin, but after some Wine developer has made that effort (or if they already have that Cygwin expertise), then in addition they have complete access to the Cygwin source code for the Windows calls that are not properly working on Wine, and that is a big advantage in knocking off Wine problems one by one that are turned up this way. And I want to emphasize again that fixing those Wine problems should be a big advantage for _all_ Windows applications being run on Wine, not just Cygwin. > [...] [A]sking > others to spend their time to debug issues that fix Cygwin isn't > likely to find many volunteers. Well, there is at least one volunteer working on this, and he has made some good progress. Andrey Turkin's small patch for Wine (see his attachment at <http://bugs.winehq.org/show_bug.cgi?id=24018>) combined with the Cygwin fork fix now works for him and me in the sense that the postinstall scripts now all run without catastrophic runtime errors or hangs. I have added all the details about my experience with that breakthrough to that bug report. I have included an attachment there of a script to allow convenient updating of cygwin1.dll with the fork-fixed version. Note, the first postinstall script that is run creates an empty /etc/fstab rather than the desired result and also fails to create /dev. These errors very likely create problems for the other postinstall scripts and might be some/all of the reason why four of those scripts generate error messages and have non-zero return codes. So the status right now is that the postinstall scripts run by setup.exe on Wine still do not give clean results, but the results are much better than before the Cygwin fork fix and Andrey's patch. There are probably a couple of Wine bugs that still need to be fixed before clean postinstall script results can be achieved. Of course, a clean result from the postinstall stage of setup.exe would only be the first step, but that step should give solid footing for finding and fixing the rest of the Cygwin on Wine bugs. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

July 5, 2013

Re: po: Update Simplified Chinese translation. (newer)

by Jactry Zeng

2013/7/5 Andrew Eikum <aeikum(a)codeweavers.com> > > It comes basically from the ERole enumeration in MMDevAPI: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%… > > The "Input device" maps to eConsole (and eMultimedia, which is > identical to eConsole in modern Windows). The "Voice input device" > maps to eCommunications. > > So, "human voice" is the intended meaning. > > Hope this clears it up! Thanks Andrew. I will add the new translation next time I sent a new patch. -- Regards, Jactry Zeng

July 5, 2013

Re: po: Update Simplified Chinese translation. (newer)

by Qian Hong

On Fri, Jul 5, 2013 at 11:49 PM, Andrew Eikum <aeikum(a)codeweavers.com> wrote: > It comes basically from the ERole enumeration in MMDevAPI: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%… > > The "Input device" maps to eConsole (and eMultimedia, which is > identical to eConsole in modern Windows). The "Voice input device" > maps to eCommunications. > > So, "human voice" is the intended meaning. > > Hope this clears it up! Ah thanks, great info! This is exactly what we need :) -- Regards, Qian Hong - http://www.winehq.org

July 5, 2013

Re: po: Update Simplified Chinese translation. (newer)

by Andrew Eikum

It comes basically from the ERole enumeration in MMDevAPI: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370842%28v=vs.85%… The "Input device" maps to eConsole (and eMultimedia, which is identical to eConsole in modern Windows). The "Voice input device" maps to eCommunications. So, "human voice" is the intended meaning. Hope this clears it up! Andrew On Fri, Jul 05, 2013 at 11:43:23PM +0800, Qian Hong wrote: > Hi Andrew, > > While discussing the translation of 'Voice output device' and 'Voice > input device' in winecfg, Jactry and I have no idea what does 'voice' > mean here. > Voice could be translated to both '声音‘ and '语音' in Chinese, the former > means all kinds of sound, the latter means human voice only, which > one is more accurate? > > I know you've subscribed wine-devel, I CC'ed you because you are the > original contributor to the 'voice input device' related code. Thanks > a lot! > > On Fri, Jul 5, 2013 at 9:53 PM, Jactry Zeng <jactry92(a)gmail.com> wrote: > > Please ignore the first patch, I modify some in this one. > > Thanks advice from Qian Hong. > > > > > > > > > > -- > Regards, > Qian Hong > > - > http://www.winehq.org

July 5, 2013

Re: po: Update Simplified Chinese translation. (newer)

by Qian Hong

Hi Andrew, While discussing the translation of 'Voice output device' and 'Voice input device' in winecfg, Jactry and I have no idea what does 'voice' mean here. Voice could be translated to both '声音‘ and '语音' in Chinese, the former means all kinds of sound, the latter means human voice only, which one is more accurate? I know you've subscribed wine-devel, I CC'ed you because you are the original contributor to the 'voice input device' related code. Thanks a lot! On Fri, Jul 5, 2013 at 9:53 PM, Jactry Zeng <jactry92(a)gmail.com> wrote: > Please ignore the first patch, I modify some in this one. > Thanks advice from Qian Hong. > > > -- Regards, Qian Hong - http://www.winehq.org

July 5, 2013

Re: [PATCH] windowscodecs/tests: Fix a test failure [newwtb and other]

by Dmitry Timoshkov

Detlef Riekenberg <wine.dev(a)web.de> wrote: > - /* global palette */ > + /* global palette. This succeed since win7sp1 with platform update / win8 */ This comment is not helpful. > hr = IWICBitmapDecoder_CopyPalette(decoder, palette); > - ok(hr == WINCODEC_ERR_FRAMEMISSING, > - "expected WINCODEC_ERR_FRAMEMISSING, got %#x\n", hr); > + ok((hr == S_OK) || (hr == WINCODEC_ERR_FRAMEMISSING), > + "expected S_OK or WINCODEC_ERR_FRAMEMISSING, got %#x\n", hr); One of test results should be marked as broken, and in the S_OK case the resulting palette should be tested and released. I'd guess that newer version should be taken as a model to follow, and Wine implementation should be fixed appropriately. -- Dmitry.

July 5, 2013

Re: po: Revert Japanese shell path name updates.

by Francois Gouget

On Thu, 4 Jul 2013, Akihiro Sagawa wrote: [...] > I got it. I'll resubmit the patch. > > Actually, it was removed by 4c4e51700932e9ed6355afc1bf8ca0d18282634f. > I misunderstood the intention of the commit at that time. At the time the PO files were new and had been populated from the RC files which were incompletely translated. So I made a pass over them to remove strings that seemed to unintentionally not be translated so that a translator would later get a chance to look at them again. > As I mention in the last mail[2], patch 91758[3] has some issues, > especially when retrieving shell path names. Although path names are > not localized in Japanese Windows Vista (and its successors), they are > (mistakenly?) included in the last commit. Note that although the on-disk directory names are not translated in Windows 7, the shell folders contain desktop.ini files that result in the display names to be translated (see attached screenshot). On Windows XP at least some shell folder names were getting translated on-disk. This was the case for 'Program Files' in French for instance. I don't know what was done for Japanese in that case though. Now as far as I can tell Wine does not use the desktop.ini approach at this point. So whether to translate these shell folder names depends on: * Whether they were translated in the Japanese Windows XP editions. * These names are also used to detect the corresponding Unix folders, at least in the non-XDG case. The Unix folder names may be translated so it requires us to look for them by the right name. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

July 4, 2013

Re: RFC: Three dots or Unicode ellipsis character

by Francois Gouget

On Wed, 3 Jul 2013, Francois Gouget wrote: > > Wine uses three dots (...) rather than the Unicode ellipsis character > (…) except in the Czech and Taiwanese translations that use the Unicode > ellipsis character. > > I think we should be consistent but the question is which to use. Ah found it. Akihiro Sagawa had sent me a link to Microsoft's Language Portal with language-specific Style Guides: https://www.microsoft.com/Language/en-us/StyleGuides.aspx The Japanese one says: In Japanese, use three half-width periods as used in the source text. So that settles it. While I was at it I also checked for some other languages: Simplified Chinese: English (...) is used in both software and document localization. Traditional Chinese: English (...) is used in both software and document localization. Keep in mind the following when using ellipses/suspension points: If a UI containing ellipses appears in a descriptive string or procedural steps, you could omit ellipses. Click "About..." for more information. 如需詳細資訊,請按一下 [關於]。 "About..." is a UI. When it is enclosed in [ ], ellipses should be omitted. Czech: Ellipsis is commonly used both in English and Czech UI to denote a control (such as a push button or a menu item) that invokes a dialog window where the user enters additional input (such as Browse... = (+) Procházet...). Please that due to compatibility concerns, the ellipsis character (ALT+0133) should not be used in these cases. Use three dots instead. When quoting such UI items in text (software controls as well as documentation), the three dots are omitted entirely. Example: (-) Klikněte na tlačítko Procházet... (+) Klikněte na tlačítko Procházet. Note that any standard punctuation (except period) that is required by the syntax of the sentence, should still be added after the ellipsis. In Czech localized texts, it is recommended to avoid using the ellipsis entirely. Note: The (-) denotes what not to do and the (+) what should be done. I think these style guides are going to be a great resource for translators... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Be careful of reading health books, you might die of a misprint. -- Mark Twain

July 4, 2013

Re: Possible help or direction to build Win to Linux pass through device - resent

by Vincent Povirk

> Do you mean by winelib dll that the wine/Liunux native .so style DLL > is built which is linked/imported through fakedlib to the application? > That looks like feasible solution and I would consider this solution > if there is interrest in the application in Linux community > and not enough resource is find to port it as full Linux native > version. I don't know what "fakedlib" is. I know you can use LoadLibrary/GetProcAddress, or create a Windows DLL with the same abi and link to that. There may be some other way to generate a .lib file that I'm not aware of. > How is it with wine version dependency if the wine .so style DLL uses > only bunch of Linux calls (open, close, read, write, ioctl) and exports > some small set of the functions to the application? The abi for winelib .dll.so files has been stable for a long time, but of course such files will be specific to Linux and will also rely on the abi of libraries they import (including glibc, which means it's a good idea to build on a relatively old distribution for better compatibility). I think it's possible to rename the .dll.so file to .dll and put it with your application's files, if you don't want to ship your own version of Wine or require a special build. > I have done some more search to find narrow passes which limits > my initial idea of the driver based solution. I am sending my dump > there because it can be usesfull to somebody else (or even to me > if I find time one day and return to the problem). This goes over my head. It sounds like you know a lot about Windows drivers, and it's too bad you don't have time to help us with that.

July 4, 2013

Re: Possible help or direction to build Win to Linux pass through device - resent

by Pavel Pisa

Hello all, thanks much for replies. On Tuesday 02 of July 2013 18:15:28 Vincent Povirk wrote: > > What others have suggested in similar situations is to build a Linux > > application that speaks to the device driver directly, and provides a > > socket interface, then use sockets from the Windows program to talk to > > the device. > > I didn't think of that. A winelib dll providing an API for directly > accessing your devices (which you can use from a normal Windows > program) might be simpler than a separate process if you're willing to > modify the application. Do you mean by winelib dll that the wine/Liunux native .so style DLL is built which is linked/imported through fakedlib to the application? That looks like feasible solution and I would consider this solution if there is interrest in the application in Linux community and not enough resource is find to port it as full Linux native version. How is it with wine version dependency if the wine .so style DLL uses only bunch of Linux calls (open, close, read, write, ioctl) and exports some small set of the functions to the application? Another suggestion to use socket is also reasonable. In the fact we have support for indirect uLAN access over TCP/IP implemented in other utilities and programs but for this actual application it is missing and would require more intrusive modifications. Its design is quite old but it provides still valuable services to many old and new users. I have done some more search to find narrow passes which limits my initial idea of the driver based solution. I am sending my dump there because it can be usesfull to somebody else (or even to me if I find time one day and return to the problem). The driver is run by Wine in the separate process. This process calls get_next_device_request which is processed on the Wine Server side in wine-git/server/device.c: /* retrieve the next pending device ioctl request */ DECL_HANDLER(get_next_device_request) Even that name suggest that it is processing generic requests, actual implementation is really minimal and allows only to encode simple IOCTLs which use BUFFERED method to pass data. But extension to more complete version is possible. It is questionable if more fields and operations codes should be added or if the better way to achieve complete functionality is to provide mechanism to pass whole IRP from wine server to the service tasks. This would be more close to the real Windows implementation and original idea of microkernel based OS. But whole IRP is quite huge and some mechanism to pass it and associated data through shared memory would be probably much faster. In both cases, there should be maintained/exchanged at least value of the fields StackPtr->FileObject->FsContext StackPtr->FileObject->FsContext2 where drivers can store their context specific for each device open instance (IRP_MJ_CREATE). It has to be stored and read again from the HANDLE structure created/associated with file in wine/server/directory.c. Next operations needs to be propagated for our driver (and probably would cover needs of significant range of other drivers too) ulan_driver = driver; driver->MajorFunction[IRP_MJ_DEVICE_CONTROL] = ulan_dispatch; driver->MajorFunction[IRP_MJ_CREATE] = ulan_dispatch; driver->MajorFunction[IRP_MJ_CLOSE] = ulan_dispatch; driver->MajorFunction[IRP_MJ_READ] = ulan_dispatch; driver->MajorFunction[IRP_MJ_WRITE] = ulan_dispatch; driver->MajorFunction[IRP_MJ_DEVICE_CONTROL] = ulan_dispatch; driver->MajorFunction[IRP_MJ_CLEANUP] = ulan_dispatch; The analysis of the side of the started service C:\windows\system32\winedevice.exe uL_Drv wine/programs/winedevice/device.c:ServiceMain() wine_ntoskrnl_main_loop( stop_event ); wine/dlls/ntoskrnl.exe/ntoskrnl.c: wine_ntoskrnl_main_loop( HANDLE stop_event ) SERVER_START_REQ( get_next_device_request ) process_ioctl( DEVICE_OBJECT *device, ULONG code, void *in_buff, ULONG in_size, void *out_buff, ULONG *out_size ) PDRIVER_DISPATCH dispatch = device->DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]; Pointer irpStack->FileObject is filled with 0x66666666. Good source of information how full IRP setup should work can be found in React OS sources reactos/reactos/reactos/ntoskrnl/io/iomgr/irp.c and reactos/reactos/reactos/ntoskrnl/io/iomgr/iofunc.c:IopDeviceFsIoControl including FileObject /* Setup the IRP */ Irp->UserIosb = IoStatusBlock; Irp->UserEvent = EventObject; Irp->Overlay.AsynchronousParameters.UserApcRoutine = UserApcRoutine; Irp->Overlay.AsynchronousParameters.UserApcContext = UserApcContext; Irp->Cancel = FALSE; Irp->CancelRoutine = NULL; Irp->PendingReturned = FALSE; Irp->RequestorMode = PreviousMode; Irp->MdlAddress = NULL; Irp->AssociatedIrp.SystemBuffer = NULL; Irp->Flags = 0; Irp->Tail.Overlay.AuxiliaryBuffer = NULL; Irp->Tail.Overlay.OriginalFileObject = FileObject; Irp->Tail.Overlay.Thread = PsGetCurrentThread(); /* Set stack location settings */ StackPtr = IoGetNextIrpStackLocation(Irp); StackPtr->FileObject = FileObject; StackPtr->MajorFunction = IsDevIoCtl ? IRP_MJ_DEVICE_CONTROL : IRP_MJ_FILE_SYSTEM_CONTROL; StackPtr->MinorFunction = 0; /* Minor function 0 is IRP_MN_USER_FS_REQUEST */ StackPtr->Control = 0; StackPtr->Flags = 0; StackPtr->Parameters.DeviceIoControl.Type3InputBuffer = NULL; /* Set the IOCTL Data */ StackPtr->Parameters.DeviceIoControl.IoControlCode = IoControlCode; StackPtr->Parameters.DeviceIoControl.InputBufferLength = InputBufferLength; StackPtr->Parameters.DeviceIoControl.OutputBufferLength = OutputBufferLength; This is example for IOCTL. The other operations need again similar but individual setup. So I hope that this information could be usesfull for somebody. May it be that even my skeleton of the "native" driver extracted from Wine sources can be usesfull for somebody who needs to substitute functionality of some simpler driver which functionality is fully implemented in IOCTL and without per open context. http://cmp.felk.cvut.cz/~pisa/ulan/wine/ Thanks again for advises and your work, Pavel

July 4, 2013

Re: kernel/tests: Test behaviour of TPIDRURW register with threads on ARMv7

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > +#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) > +static inline void set_tpidrurw(DWORD tpidrurw) > +{ > + __asm__ volatile ("mcr p15, 0, %0, c13, c0, 2" : : "r" (tpidrurw)); > +} > + > +static inline DWORD get_tpidrurw(void) > +{ > + DWORD tpidrurw = 0; > + __asm__ volatile ("mrc p15, 0, %0, c13, c0, 2" : "=r" (tpidrurw)); > + return tpidrurw; > +} This code is gcc specific and for instance won't compile with PSDK compiler. It either needs to be protected or replaced with hex/binary form. -- Dmitry.

July 4, 2013

Re: RFC: Three dots or Unicode ellipsis character

by Dmitry Timoshkov

Francois Gouget <fgouget(a)free.fr> wrote: > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? 3 dots should be used in order to keep compatibility with bitmap fonts, fonts that don't have the ellipsis glyph and ansi APIs (GetMenuItemInfoA/GetWindowTextA). -- Dmitry.

July 4, 2013

Re: msxml3/tests: Add additional conformance tests to the xpath tests (try 2)

by Alexandre Julliard

John Chadwick <johnwchadwick(a)gmail.com> writes: > This patch adds additional xpath tests to the msxml3 tests. Following > Nikolay Sivov's advice, these provide a wide range of new tests, two > of which currently fail in Wine (for reasons previously described.) > These are now marked 'todo' in a much cleaner way. It doesn't work here: ../../../tools/runtest -q -P wine -M msxml3.dll -T ../../.. -p msxml3_test.exe.so domdoc.c && touch domdoc.ok domdoc.c:4468: Test succeeded inside todo block: query=ancestor-or-self::node(), invalid node list: D1 E2.D1, expected D1 E2.D1 domdoc.c:4468: Test succeeded inside todo block: query=(//a[1])[last()], invalid node list: E1.E4.E2.D1, expected E1.E4.E2.D1 make: *** [domdoc.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

July 3, 2013

Fwd: Re: RFC: Three dots or Unicode ellipsis character

by Michael Stefaniuc

-------- Original Message -------- Subject: Re: RFC: Three dots or Unicode ellipsis character Date: Wed, 03 Jul 2013 19:32:15 +0200 From: Michael Stefaniuc <mstefani(a)redhat.com> To: Francois Gouget <fgouget(a)free.fr> On 07/03/2013 04:45 PM, Francois Gouget wrote: > > Wine uses three dots (...) rather than the Unicode ellipsis character > (…) except in the Czech and Taiwanese translations that use the Unicode > ellipsis character. > > I think we should be consistent but the question is which to use. > > > I looked at the Windows interface guidelines and they don't have > anything to say on this. > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punct… > http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellip… > > Looking at what other platforms do, the Apple interface guidelines > recommend using the Unicode ellipsis character saying assistive > technologies need it. The GNOME and KDE guidelines don't have an > official position but seem to use the Unicode character anyway: > > http://simos.info/blog/archives/17 > > > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? How will the substitution work in the W2A case? bye michael

July 3, 2013

Windows RT Applications finally can run in Wine/ARM with upcoming Linux releases

by André Hentschel

Hi, Wanted to let you know that the patch that allows that just got committed in Linus tree: [1] This means that Kernel 3.11 will have everything to run applications ported to Windows RT. A good list of such applications and libraries can be found at [2]. See [3] & [4] for more information on the Wine side. [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a… [2] http://forum.xda-developers.com/showthread.php?p=36534446 [3] http://bugs.winehq.org/show_bug.cgi?id=31322 [4] http://bugs.winehq.org/show_bug.cgi?id=31308

July 3, 2013

Re: RFC: Three dots or Unicode ellipsis character

by Akihiro Sagawa

On Wed, 3 Jul 2013 16:45:24 +0200 (CEST), Francois Gouget wrote: > So should we go with the flow and switch to using ellipsis characters or > should we stick with three dots? In most Japanese fonts, ellipsis character (U+2026) is designed like midline horizontal ellipsis (U+22EF). For instance, please look at 0x8163 in codepage 932 chart [1]. [1] http://msdn.microsoft.com/en-us/goglobal/gg638593 If we use ellipsis character (U+2026), Japanese user gets different impression from the character. Therefore, I prefer "three dots" style. The reason of this behaviour is Japanese Industrial Standard, JIS X 0208. JIS X 0208 defines 3-dot leader character. As its example glyph is three middle dots, most font vendors designed the glyph like that. In Unicode conversion, the character is mapped into U+2026. Thus, its glyph is not like ellipsis. Regards, Akihiro Sagawa

July 3, 2013

Re: po: Revert Japanese shell path name updates.

by Akihiro Sagawa

On Wed, 03 Jul 2013 16:23:11 +0200, Alexandre Julliard wrote: > Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > > As I mention in the last mail[2], patch 91758[3] has some issues, > > especially when retrieving shell path names. Although path names are not > > localized in Japanese Windows Vista (and its successors), they are > > (mistakenly?) included in the last commit. > > Then they should be explicitly "translated" to the same English string > instead of an empty string, this way it doesn't look like the > translation is missing. I got it. I'll resubmit the patch. Actually, it was removed by 4c4e51700932e9ed6355afc1bf8ca0d18282634f. I misunderstood the intention of the commit at that time. Regards, Akihiro Sagawa

July 3, 2013

RFC: Three dots or Unicode ellipsis character

by Francois Gouget

Wine uses three dots (...) rather than the Unicode ellipsis character (…) except in the Czech and Taiwanese translations that use the Unicode ellipsis character. I think we should be consistent but the question is which to use. I looked at the Windows interface guidelines and they don't have anything to say on this. http://msdn.microsoft.com/en-us/library/windows/desktop/aa974176.aspx#punct… http://msdn.microsoft.com/en-us/library/windows/desktop/aa511453.aspx#ellip… Looking at what other platforms do, the Apple interface guidelines recommend using the Unicode ellipsis character saying assistive technologies need it. The GNOME and KDE guidelines don't have an official position but seem to use the Unicode character anyway: http://simos.info/blog/archives/17 So should we go with the flow and switch to using ellipsis characters or should we stick with three dots? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 145 = 1! + 4! + 5!

July 3, 2013

Re: po: Revert Japanese shell path name updates.

by Alexandre Julliard

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Could you revert recent Japanese translation updates[1] or commit > attached patch? > As I mention in the last mail[2], patch 91758[3] has some issues, > especially when retrieving shell path names. Although path names are not > localized in Japanese Windows Vista (and its successors), they are > (mistakenly?) included in the last commit. Then they should be explicitly "translated" to the same English string instead of an empty string, this way it doesn't look like the translation is missing. -- Alexandre Julliard julliard(a)winehq.org

July 3, 2013

Re: gdiplus: Added support for UTF16 encoded strings in load_ttf_name_id

by Piotr Caban

On 07/03/13 13:34, Alexandre Julliard wrote: > Piotr Caban <piotr(a)codeweavers.com> writes: > >> This patch fixes bug 33880. It's reported as regression but I think >> that it stopped working because of game update. > > I would guess that it's because gdi32 is properly loading localized > names now. Gdiplus should most likely replicate that method. > I'll try to duplicate the code inside gdiplus. Thanks, Piotr

July 3, 2013

po: Revert Japanese shell path name updates.

by Akihiro Sagawa

Could you revert recent Japanese translation updates[1] or commit attached patch? As I mention in the last mail[2], patch 91758[3] has some issues, especially when retrieving shell path names. Although path names are not localized in Japanese Windows Vista (and its successors), they are (mistakenly?) included in the last commit. To prove this, I submitted a job to winetestbot [4]. However, new winetestbot seems to be stuck. Alternatively, I attach my Japanese Windows 7 result. The line which begins shellpath.c:443 is my additional output. You can see that all path names are not translated. [1] http://source.winehq.org/git/wine.git/commit/0fb9de61a5026ac6cf16bc3385c382… [2] http://www.winehq.org/pipermail/wine-devel/2013-June/100377.html [3] http://source.winehq.org/patches/data/97158 [4] https://newtestbot.winehq.org/JobDetails.pl?Key=1432 --- po/ja.po | 63 +++++++++++++++++++++++++++++++------------------------------- 1 file changed, 31 insertions(+), 32 deletions(-)

July 3, 2013

Re: gdiplus: Added support for UTF16 encoded strings in load_ttf_name_id

by Alexandre Julliard

Piotr Caban <piotr(a)codeweavers.com> writes: > This patch fixes bug 33880. It's reported as regression but I think > that it stopped working because of game update. I would guess that it's because gdi32 is properly loading localized names now. Gdiplus should most likely replicate that method. -- Alexandre Julliard julliard(a)winehq.org

July 3, 2013

Re: wininet/tests: Statically initialize and name the notification_cs critical section.

by Marvin

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 http://testbot.winehq.org/JobDetails.pl?Key=26207 Your paranoid android. === WINEBUILD (build) === Make failed

July 3, 2013

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

by Hans Leidekker

On Tue, 2013-07-02 at 20:34 +0900, Rosen Diankov wrote: > you are right again, i'll be more careful. now, i've addressed every > problem except creating the patches with git. any help would be > appreciated. See http://wiki.winehq.org/GitWine > --- wine-1.6-rc4-old/dlls/wbemprox/builtin.c 2013-06-29 04:53:55.000000000 +0900 > +++ wine-1.6-rc4/dlls/wbemprox/builtin.c 2013-07-02 19:30:39.157916619 +0900 > @@ -168,6 +168,8 @@ > {'M','a','n','u','f','a','c','t','u','r','e','r',0}; > static const WCHAR prop_maxclockspeedW[] = > {'M','a','x','C','l','o','c','k','S','p','e','e','d',0}; > +static const WCHAR prop_currentclockspeedW[] = > + {'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0}; > static const WCHAR prop_memberW[] = > {'M','e','m','b','e','r',0}; > static const WCHAR prop_methodW[] = > @@ -381,6 +383,7 @@ > { prop_familyW, CIM_UINT16, VT_I4 }, > { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC }, > { prop_maxclockspeedW, CIM_UINT32, VT_I4 }, > + { prop_currentclockspeedW, CIM_UINT32, VT_I4 }, > { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC }, > { prop_numcoresW, CIM_UINT32, VT_I4 }, > { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 }, > @@ -633,6 +636,7 @@ > UINT16 family; > const WCHAR *manufacturer; > UINT32 maxclockspeed; > + UINT32 currentclockspeed; > const WCHAR *name; > UINT32 num_cores; > UINT32 num_logical_processors; > @@ -1690,20 +1694,30 @@ > regs_to_str( regs, 16, name + 32 ); > } > } Please keep properties sorted alphabetically. > -static UINT get_processor_maxclockspeed( void ) > +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT* currentclockspeed ) > { > PROCESSOR_POWER_INFORMATION *info; > - UINT ret = 1000, size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); > + UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); > NTSTATUS status; > - > + UINT valueswritten=0; > if ((info = heap_alloc( size ))) > { > status = NtPowerInformation( ProcessorInformation, NULL, 0, info, size ); > - if (!status) ret = info[0].MaxMhz; > + if (!status) > + { > + *maxclockspeed = info[0].MaxMhz; > + *currentclockspeed = info[0].CurrentMhz; > + valueswritten = 1; > + } > heap_free( info ); > } > - return ret; > + if( valueswritten == 0 ) > + { > + *maxclockspeed = 1000; > + *currentclockspeed = 1000; > + } > } You don't need an extra variable, just return early.

July 3, 2013

Re: [docs] winedev: Update backtrace and relay examples

by André Hentschel

On 03.07.2013 00:02, Frédéric Delanoy wrote: > On Tue, Jul 2, 2013 at 11:39 PM, André Hentschel <nerv(a)dawncrow.de> wrote: >> --- >> en/winedev-debugger.sgml | 269 ++++++++++++++++++++++++++++++++++++++--------- >> 1 file changed, 222 insertions(+), 47 deletions(-) >> >> diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml >> index b877063..31046c0 100644 >> --- a/en/winedev-debugger.sgml >> +++ b/en/winedev-debugger.sgml >> @@ -280,31 +280,208 @@ winedbg hl.exe -windowed >> These usually show up like this: >> </para> >> <screen> >> -|Unexpected Windows program segfault - opcode = 8b >> -|Segmentation fault in Windows program 1b7:c41. >> -|Loading symbols from ELF file /root/wine/wine... >> -|....more Loading symbols from ... >> -|In 16 bit mode. >> ... > > Maybe you can leave the 16 bit stuff there and have the 32 bit as an > addition, not a replacement? Even the 16-bit backtrace doesn't look like that anymore, so no reason to leave it there. It's just totally outdated.

July 2, 2013

Re: [docs] winedev: Update backtrace and relay examples

by Frédéric Delanoy

On Tue, Jul 2, 2013 at 11:39 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > en/winedev-debugger.sgml | 269 ++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 222 insertions(+), 47 deletions(-) > > diff --git a/en/winedev-debugger.sgml b/en/winedev-debugger.sgml > index b877063..31046c0 100644 > --- a/en/winedev-debugger.sgml > +++ b/en/winedev-debugger.sgml > @@ -280,31 +280,208 @@ winedbg hl.exe -windowed > These usually show up like this: > </para> > <screen> > -|Unexpected Windows program segfault - opcode = 8b > -|Segmentation fault in Windows program 1b7:c41. > -|Loading symbols from ELF file /root/wine/wine... > -|....more Loading symbols from ... > -|In 16 bit mode. > ... Maybe you can leave the 16 bit stuff there and have the 32 bit as an addition, not a replacement? Frédéric

July 2, 2013

Mayhem analysis of Wine

by André Hentschel

Hi, wanted to let you know that i've seen "Reporting 1.2K crashes" [1] and searched for Wine results [2] and it seems we raised no issues with that "testsuite". Though it's not designed to test Wine, i felt happy not to see Wine on a list of faulty applications ;) [1] http://lists.debian.org/debian-devel/2013/06/msg00720.html [2] http://forallsecure.com/programs/search?search=wine

July 2, 2013

Re: [PATCH 3/3] user32: Deactivate popup menu if accelerator key not found when tracking top level menu.

by Qian Hong

Update: The commit message is a bit misleading, should be 'user32: Deactivate menu if accelerator key not found when tracking top level menu.', removed the word 'popup'. Sorry for the trouble. On Wed, Jul 3, 2013 at 2:45 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > --- > dlls/user32/menu.c | 6 +++++- > dlls/user32/tests/menu.c | 6 +++--- > 2 files changed, 8 insertions(+), 4 deletions(-) > > > > > -- Regards, Qian Hong - http://www.codeweavers.com

July 2, 2013

Re: [PATCH 2/3] user32/tests: Added tests for non-existent accelerator key.

by Qian Hong

Hello, On Wed, Jul 3, 2013 at 2:41 AM, Qian Hong <qhong(a)codeweavers.com> wrote: > Current menu test code may hide some failure tests [1], with the attached > patch, all failure tests could be detected [2]. > > > [1] https://testbot.winehq.org/JobDetails.pl?Key=26191 > [2] https://testbot.winehq.org/JobDetails.pl?Key=26190 Please ignore the above comments, they should be in [Patch 1/3], sorry for the mistake. They attached patch itself is OK. Thanks. -- Regards, Qian Hong - http://www.codeweavers.com

July 2, 2013

Re: Wine release 1.6-rc4

by Frédéric Delanoy

On Sat, Jun 29, 2013 at 10:30 AM, Neumann, A. D. <info.adneumann(a)googlemail.com> wrote: > Hello, > > I changed my email address. Please send this information to: > info.adneumann(a)t-online.de > > Thank you! > D. Neumann You have to update your email address on the wine-announce mailing list (http://www.winehq.org/mailman/listinfo/wine-announce) This list is for wine development only. F. Delanoy

July 2, 2013

Re: Mac OS X releases

by Jeremiah Flerchinger

Wolf, What "additional features" do you mean? I've used osxwinebuilder. I have packaged some builds Wine using osxwinebuilder at sourceforge.net/projects/darwine/ in case you're interested. The builds there have pure Wine in the Wine.app/Contents/Resources folder of the installable Mac app file. On Mon, Jul 1, 2013 at 7:29 PM, Wolf Kappesser <wolf.kappesser(a)gmail.com> wrote: > Hello, > > my name is Wolf I am from germany and use OSX 10.8 to develop my apps, play games etc. I have read that there is no one, who compile the OSX version of WINE. I would do this. I have tried the osxwinebuilder script from http://code.google.com/p/osxwinebuilder and it did the job. > I have download the old 1.5.30 wine for Mac and it has some additional features. They doesn't exist in the pure osxwinebuilder build. Where I can get them? > I would give the OSX wine to the community, what I need to to? I have read that I should post to this list to get additional advices. > > Greets > Wolf > > >

July 2, 2013

Re: Possible help or direction to build Win to Linux pass through device - resent

by Vincent Povirk

> What others have suggested in similar situations is to build a Linux > application that speaks to the device driver directly, and provides a socket > interface, then use sockets from the Windows program to talk to the device. I didn't think of that. A winelib dll providing an API for directly accessing your devices (which you can use from a normal Windows program) might be simpler than a separate process if you're willing to modify the application.

July 2, 2013

Re: Possible help or direction to build Win to Linux pass through device - resent

by Juan Lang

Hi Vincent, Pavel, On Tue, Jul 2, 2013 at 8:44 AM, Vincent Povirk <madewokherd(a)gmail.com>wrote: > Since you're not prepared to spend a lot of time improving Wine's > driver support, it sounds like modifying core parts of Wine > specifically to support your application is the best approach. > An alternative is to modify your application for use with Wine. What others have suggested in similar situations is to build a Linux application that speaks to the device driver directly, and provides a socket interface, then use sockets from the Windows program to talk to the device. This is usually straightforward enough, and doesn't require learning lots of Wine internals to get working. --Juan

July 2, 2013

Re: Possible help or direction to build Win to Linux pass through device - resent

by Vincent Povirk

I don't know much about this, but it sounds like a driver is the right way to do this. It's probably just a case of Wine's driver support not being good enough yet to support what you want to do. So the less intrusive/hacky way to fix this would be to improve Wine's driver support, ideally to a point where you can run the same driver on Windows and Wine (but I don't know if that's possible). I think the limitation of Wine being unable to do file i/o without a native fd has also come up with message mode named pipes, which are still unimplemented and are semantically different from any native file object we can use. Details of Wine's implementation, such as object_ops or the translation of ioctls, are generally not exposed to windows or winelib software, because they can change. The correct long term solution is to implement the Windows API which cannot change and is within Wine's scope. Since you're not prepared to spend a lot of time improving Wine's driver support, it sounds like modifying core parts of Wine specifically to support your application is the best approach.

July 2, 2013

Re: Duplicate UUID in oleaut32:tmarshal test

by Jacek Caban

On 06/30/13 23:29, Thomas Faber wrote: > I just tried running midl on dlls/oleaut32/tests/tmarshal.idl and it > complained: > tmarshal.idl(83) : error MIDL2270 : duplicate UUID. Same as : ItestDual [ Interface 'ITestSecondDisp' ] > > This doesn't seem like it's intentional. But just giving > ITestSecondDisp a new uuid causes the following test failures on > Windows: > tmarshal.c:1861: Test failed: external_connections = 2 > tmarshal.c:1864: Test failed: external_connections = 2 > tmarshal.c:192: Test failed: fLastReleaseCloses = 1 > > > I could try to figure this out, but it's probably better if someone > familiar with the subject could have a look instead. > > (also, assuming this is a bug in the test, we might want to add that > check to widl, it seems pretty useful ;]) Thanks for the report. This was indeed a stupid mistake and after fixing it, the behaviour is more logical. I will send a patch fixing tests. Fixing todo_wine may wait until after code freeze. Current Wine behaviour shouldn't cause problems. Thanks, Jacek

July 2, 2013

Re: msxml3/tests: add additional conformance tests that show incorrect xpath behavior in wine

by Nikolay Sivov

On 6/29/2013 20:26, John Chadwick wrote: > On Sat, Jun 29, 2013 at 4:48 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: >> On 6/27/2013 11:46, John Chadwick wrote: >> >>> + /* msxml's selectNodes returns a document ordered nodelist, >>> regardless of >>> + * whether or not the xpath nodelist was document ordered... */ >>> + >>> ole_check(IXMLDOMNode_selectNodes(rootNode,_bstr_("ancestor-or-self::node()"), >>> &list)); >>> + todo_expect_list_and_release(list, "D1 E2.D1"); >> Please use explicit check for return value, like ok(hr == S_OK, "...");, > Which return value am I missing? FWIW, I'm doing what the other tests > are doing, as far as I can tell. What I mean is that use of macros like ole_check() is discouraged, it's better to have explicit check for return value. > >> also you probably don't need another macro for list checking, >> isn't it enough to wrap expect_list_and_release() in todo_wine {} ? > Could it be that simple? I tried to do >> todo_wine expect_list_and_release(list, "D1 E2.D1"); > But it fails before the actual test occurs, because another test > inside the macro succeeds, apparently. Are you saying if I wrap the > expect_list_and_release macro call in a scope, it will work? I will > try. Yes, I see what you mean. In order to improve situation I'd suggest to move to using table of test queries and results. This way you have less code and no duplication, todo flag should just be stored in test data. We already have some tests done this way, it's much easier to maintain. > > I figured creating a new macro would be a better solution than > duplicating the code separately in two locations, but if it'd be > better to just not use the macro, then that's simple enough to fix. >

July 2, 2013

Re: [patch] full translation update for 16 rc4

by Henri Verbeet

On 30 June 2013 09:36, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > On Sun, Jun 30, 2013 at 6:08 AM, 中川祥 <matyapiro31(a)gmail.com> wrote: >> > Hi, please resubmit this patch with your full name transliterated in English. > I may just be missing something, but is there actually a good reason for that?

July 2, 2013

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

by Rosen Diankov

you are right again, i'll be more careful. now, i've addressed every problem except creating the patches with git. any help would be appreciated. . 2013/7/2 Hans Leidekker <hans(a)codeweavers.com>: > On Mon, 2013-07-01 at 18:08 +0900, Rosen Diankov wrote: >> you are right, i'm attaching a new patch. > > You didn't address all comments. > >

July 2, 2013

Re: widl: Do not generate C structure for empty interfaces. (try 2)

by Jacek Caban

On 06/30/13 23:14, Thomas Faber wrote: > On 2013-06-27 13:33, Jacek Caban wrote: >> That >> said, if such interfaces are just obscure special case, I would say we >> shouldn't care. We may easily avoid them (I just sent a patch avoiding >> it in mshtml). > Ah, I hadn't even considered changing the interface. Seemed like it was > something mandated by Mozilla's use of it. > This indeed seems to be the best solution to the immediate problem of > mshtml not building with MSVC. > Thanks! In general, Mozilla uses their own variant of COM, called XPCOM. It happens to be similar enough to MS variant of COM that we may use widl to generate its binary compatible headers, but if there is any incompatibility, fixing it in nsiface.idl is preferred over hacking widl. >> If you want a better solution to avoid such problems in the future, I >> would suggest adding an error, like midl does. This will, however, >> require some more changes in Wine. At least MSHTML already has an >> interface identical to IUnknown (nsISupports), which would cause the >> error. This should be solvable with some tricks. > That sounds like the smart thing to do. I've attached the simplest > version that comes to mind. > The interfaces I needed to exempt were IUnknown (naturally), > ID3DInclude (which PSDK seems to define via cpp_quote), and nsISupports > as you already mentioned. > Midl also seems to have an "if not inside a library" condition, which > I'll try to add as well. I'd have liked to use is_object in widl, but > that also triggers on the odl attribute. > > I'll send it to -patches once I'm satisfied with it, but I'm pretty > fond of the simple approach already. Let me know if you have any > comments. I don't think we want to maintain such a list of special interfaces in widl sources. IUnknown is a special case in many aspects, so that's fine. ID3DInclude is something that definitely shouldn't be there. It's also small enough that cpp_quote should be fine for this. nsISupports is, as I said earlier, something that would be better worked around in nsiface.idl. The attached patch does that, although now there will probably be duplicated UUID error on midl. That's also something we could work around with some preprocessor tricks... If this would be generic enough problem, we could add some widl extension, like a special attribute, but your findings show that it's too rare to mitigate that. Thanks, Jacek

July 2, 2013

Patch 96895

by Fabian Ebner

Is something wrong with this patch? It's just a translation update and Matteo Bruni said it looks good to him: http://www.winehq.org/pipermail/wine-devel/2013-June/100264.html ~Fabian

July 2, 2013

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

by Hans Leidekker

On Mon, 2013-07-01 at 18:08 +0900, Rosen Diankov wrote: > you are right, i'm attaching a new patch. You didn't address all comments.

July 2, 2013

How not to ask for help Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine

by Hin-Tak Leung

--- On Tue, 2/7/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > > Going personal and accusing others of being biased is > not a way of > getting help. ...In short, I have > a > prejudice against anyone stating anecdotal evidence > concerning issues > with _any_ open-source software if they don't back up that > anecdotal > evidence with a solid bug report. For example, you > stated some > anecdotal evidence about a bug in Cygwin "cat", but when I > requested a > reference for your associated bug report to Cygwin you were > silent. > That told me a lot. ... That tells you only one thing: I don't care about Cygwin enough now to bother filing one more bug among those already filed. My time is more valuable than that. 13 years ago I used it daily and I made my own contributions, and that was then. Half of the time I file bugs on various projects because I have patches to attach/send, and this is not the case with cygwin now, and will not be. I don't intend to file a bug because I don't intend spend time fixing it. You wish. I am not the one asking for help - you are. Launching personal attacks on people trying to help you is just not the way to do it. Nor is exaggeration, nor is 20-line of [lack of] life included in every e-mail. If you want help, ask for it, nicely, and keep it short.

July 2, 2013

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Austin English

On Mon, Jul 1, 2013 at 7:11 PM, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > On 2013-07-01 19:58+0100 Hin-Tak Leung wrote: > >> --- On Mon, 1/7/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: >> ... I hope your negative >>> >>> attitude >>> toward the Cygwin toolchain is not typical of such >>> developers. After >>> all, even though the Windows GNU toolchain code bases have >>> diverged >>> between the two groups of developers, there is still a >>> common interest >>> between MinGW and Cygwin developers regarding getting the >>> GNU >>> toolchain to work properly on Windows. >> >> ... >> > >> Look. You have been advised a few times, that it is possible and > > even easy to bypass installation-related problems and been given brief > instructions on how to do so. > > The problem discussed on this thread is not with the generic part of > the installation you have referred to but instead the problem is with > running one of the post install scripts that is invoked by setup.exe. > > >> you have also been told, *many times*, > > and *by the cygwin developers*, that you are just encounter one > problems out of many, and there are more problems to come, in the > thread you posted to the cygwin mailing list. > > Many times by you and once by a Cygwin developer. I have answered both, > but I am going to try again now since you brought it up again. > > Even if that assertion were true (something we don't know until some > Wine developer with an interest in Cygwin systematically looks at it > for the latest Wine to see how many Cygwin bugs are left for that much > improved version of Wine) it only strengthens my argument. The fact > remains, Cygwin is open-source software so in theory (i.e., the Wine > developer pursuing this opportunity will need some knowledge of > Cygwin) you know exactly what is going on with the calls to Windows > software, and you can also directly compare results for those calls > between the Wine version and Microsoft version of Windows. Therefore I > think it is obvious that Cygwin represents a good opportunity to get > rid of Wine bugs. If there are a lot of such bugs like you and the > Cygwin developer assert, then it represents even a bigger opportunity > to debug those Wine issues with exact source code in hand that > demonstrates the issue. I think we don't really know what > bugs are still left in recent Wine until a systematic evaluation is > done of Cygwin on Wine, but my argument stands whether > there are a lot of such bugs or only a few. While it's likely that debugging this (and other) Cygwin problems with Wine would find and eliminate bugs from Wine, it also takes a lot of effort and know how to do so. That time is often better spent on issues that require less effort to debug, and help more user visible applications. In other words, while fixing Cygwin issues is a valuable effort, it takes a lot of time and effort that is better spent elsewhere. If you want to spend that time and effort, feel free to do so. But asking others to spend their time to debug issues that fix Cygwin isn't likely to find many volunteers. -- -Austin

July 2, 2013

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-07-01 19:58+0100 Hin-Tak Leung wrote: > --- On Mon, 1/7/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > ... I hope your negative >> attitude >> toward the Cygwin toolchain is not typical of such >> developers. After >> all, even though the Windows GNU toolchain code bases have >> diverged >> between the two groups of developers, there is still a >> common interest >> between MinGW and Cygwin developers regarding getting the >> GNU >> toolchain to work properly on Windows. > ... > > Look. You have been advised a few times, that it is possible and even easy to bypass installation-related problems and been given brief instructions on how to do so. The problem discussed on this thread is not with the generic part of the installation you have referred to but instead the problem is with running one of the post install scripts that is invoked by setup.exe. > you have also been told, *many times*, and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list. Many times by you and once by a Cygwin developer. I have answered both, but I am going to try again now since you brought it up again. Even if that assertion were true (something we don't know until some Wine developer with an interest in Cygwin systematically looks at it for the latest Wine to see how many Cygwin bugs are left for that much improved version of Wine) it only strengthens my argument. The fact remains, Cygwin is open-source software so in theory (i.e., the Wine developer pursuing this opportunity will need some knowledge of Cygwin) you know exactly what is going on with the calls to Windows software, and you can also directly compare results for those calls between the Wine version and Microsoft version of Windows. Therefore I think it is obvious that Cygwin represents a good opportunity to get rid of Wine bugs. If there are a lot of such bugs like you and the Cygwin developer assert, then it represents even a bigger opportunity to debug those Wine issues with exact source code in hand that demonstrates the issue. I think we don't really know what bugs are still left in recent Wine until a systematic evaluation is done of Cygwin on Wine, but my argument stands whether there are a lot of such bugs or only a few. > Going personal and accusing others of being biased is not a way of getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever. Sourceforge lists you as a MinGW developer, but I believe you when you state that is only a formal association. I knew of that possibility of just a formal association so that is why I was careful to put in phrasing like "apparently", and "if this is true". I am sorry you missed that phrasing and took that as a personal attack. Regardless of your association or not with MinGW, I am still concerned the opinions you have expressed here on the Cygwin tool chain are biased. That is because I have my own bias. In short, I have a prejudice against anyone stating anecdotal evidence concerning issues with _any_ open-source software if they don't back up that anecdotal evidence with a solid bug report. For example, you stated some anecdotal evidence about a bug in Cygwin "cat", but when I requested a reference for your associated bug report to Cygwin you were silent. That told me a lot. > The cygwin people would have told you the exact same thing: running mingw on wine is fair easier and more straight-forward. That is obvious and strengthens the argument for using Cygwin as a debugging tool for Wine. > [...]and that cygwin is not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned. You are completely wrong about what I assume. Try reading what I have said earlier today. The two projects are obviously quite different which is why I have stated earlier today that Cygwin represents a different opportunity (and a more extensive opportunity because it is a lot bigger) than MinGW/MSYS to debug Wine. Of course, that opportunity is there only if Cygwin _on Microsoft Windows_ mostly works and is not riddled with bugs. I think that is a fair assumption since Cygwin does have a significant userbase that actually uses it on Microsoft Windows. Something about this opportunity to use a comparison of Cygwin's behaviour on Microsoft Windows versus the Wine version to debug Wine obviously bothers you, and because of that you have clearly stated you would prefer the Wine developers here ignore this opportunity and work on something else. However, I completely disagree with your opinion about that opportunity. Any fixes to Wine that make it more like Microsoft Windows will help _all_ Windows software being run on Wine. That said, the actual Wine developers here will probably ignore both our opinions and only investigate Cygwin on Wine if that general debugging opportunity interests them. But, of course, that is the way it should be! Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

July 2, 2013

cygwin's fork Re: [wine-devel] Re: Bug 24018 which appears to be a ... for running Cygwin on Wine

by Hin-Tak Leung

--- On Mon, 1/7/13, David Laight <david(a)l8s.co.uk> wrote: > On Mon, Jul 01, 2013 at 06:13:26PM > +0200, Peter Rosin wrote: > > > > I would like to point out that it seems that the > current bug does not > > appear to be *in* setup.exe, but rather occurs when > setup.exe runs > > a bash post-install script, where the bash.exe that > interprets the > > script depends on cygwin1.dll. If my analysis is > correct, the bug > > would occur also when duplicating the actions of > setup.exe manually. > > If you read into what cygwin does when trying to emulate > fork() it > is surprising it works at all! > > Putting some effort into getting the shell (be it bash or an > ash derivative) > and gmake to use posix_spawn() instead of fork() and adding > posix_spawn() > to cygwin (for which patches are avaiable) would speed up > cygwin no end > and probably avoid some of these bugs (and the random > fork failed errors). > > One day I'll get annoyed at some issues with cygwin and > start fixing them! > (Like getting ^C to work for windows console programs in > mintty windows.) Yap. It is fork/exec, the whole thing around process ids, and stat, inode emulation, as well. It is just not setup.exe - post-install scripts are per-package items and some packages don't have them. That has been hinted at a few times by the cygwin developers who answered and me. It is "easier" to see what the problem is (or "what the problems are"), by manually unpacking the installing packages and running the scripts by hand - as the cygwin developers had already suggested. And it is even "easier" by-passing it, if one just wants a cygwin installation to play with, by copying from a windows box. Being able to get through installation, or obtaining an installation, does not change the fact that there are fundamental technical reasons that some part of cygwin does not work well in wine. Not without some serial rewrite in cygwin *and* wine. cygwin did run on win98 . I used cygwin on win98 regularly then. posix_spawn() wasn't available on the 95/98/ME family. Since cygwin works well enough on genuine windows (..more or less...), that it can be improved/rewritten does not say the issues are less of a wine problem.

July 1, 2013

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by David Laight

On Mon, Jul 01, 2013 at 06:13:26PM +0200, Peter Rosin wrote: > > I would like to point out that it seems that the current bug does not > appear to be *in* setup.exe, but rather occurs when setup.exe runs > a bash post-install script, where the bash.exe that interprets the > script depends on cygwin1.dll. If my analysis is correct, the bug > would occur also when duplicating the actions of setup.exe manually. If you read into what cygwin does when trying to emulate fork() it is surprising it works at all! Putting some effort into getting the shell (be it bash or an ash derivative) and gmake to use posix_spawn() instead of fork() and adding posix_spawn() to cygwin (for which patches are avaiable) would speed up cygwin no end and probably avoid some of these bugs (and the random fork failed errors). One day I'll get annoyed at some issues with cygwin and start fixing them! (Like getting ^C to work for windows console programs in mintty windows.) David -- David Laight: david(a)l8s.co.uk

July 1, 2013

Re: Fix to support input of characters with diacritic symbols using AltGr

by Ken Thomases

On Jul 1, 2013, at 4:26 PM, Ken Thomases wrote: > On Jul 1, 2013, at 3:29 PM, Юрий Воротилов wrote: > >> Fix to support input of characters with diacritic symbols using AltGr (e.g. Latvian - AltGr+a=ā). >> Tested on Ubuntu 12.04 and Centos 6. >> I also have a bug opened in Crossover tracker: >> http://www.codeweavers.com/support/tickets/browse/?ticket_id=935141 >> >> --- >> dlls/winex11.drv/keyboard.c | 45 +++++++++++++++++++++++++------------------ >> include/winuser.h | 1 + >> server/queue.c | 5 ++++- >> 3 files changed, 31 insertions(+), 20 deletions(-) >> <0001-Support-input-of-characters-with-diacritic-symbols-usi.txt> > > I don't believe this is the correct approach. You don't want to be modifying the server and you can't arbitrarily add a new KEYEVENTF_* value. You can't assume that applications won't leave junk in the non-standard bits of the flags when they call SendInput() or keybd_event(). > > This needs to be implemented entirely within the X11 driver. It needs to properly translate your X11 keyboard layout into Win32 behavior. If the problem is that AltGr is mapping to VK_MENU, and thus causing key events to generate WM_SYSKEYDOWN/UP and not go through translation, then you need to make AltGr not map to VK_MENU. Although you really need to test that on Windows. My understanding is that AltGr appears to Windows apps as Alt+Control. > > In any case, I know that, on Mac OS X, the Option key is used similarly to AltGr. It accesses additional characters from the keyboard layout. This works when Option is configured in the X keymap to generate XK_Mode_switch. It requires no changes to Wine. So perhaps the right approach is to make XK_ISO_Level3_Shift and XK_ISO_Group_Shift behave the same way as XK_Mode_switch. (You could also just change your X keymap to actually map the key to XK_Mode_switch.) Oh, and I forgot to mention: please don't rename variables unnecessarily (AltGrMask -> KeyEventModifiers), make whitespace changes on lines you're not otherwise modifying (stuff in X11DRV_InitKeyboard()), or change trace formats arbitrarily (%x -> %X). -Ken

July 1, 2013

Re: Fix to support input of characters with diacritic symbols using AltGr

by Ken Thomases

On Jul 1, 2013, at 3:29 PM, Юрий Воротилов wrote: > Fix to support input of characters with diacritic symbols using AltGr (e.g. Latvian - AltGr+a=ā). > Tested on Ubuntu 12.04 and Centos 6. > I also have a bug opened in Crossover tracker: > http://www.codeweavers.com/support/tickets/browse/?ticket_id=935141 > > --- > dlls/winex11.drv/keyboard.c | 45 +++++++++++++++++++++++++------------------ > include/winuser.h | 1 + > server/queue.c | 5 ++++- > 3 files changed, 31 insertions(+), 20 deletions(-) > <0001-Support-input-of-characters-with-diacritic-symbols-usi.txt> I don't believe this is the correct approach. You don't want to be modifying the server and you can't arbitrarily add a new KEYEVENTF_* value. You can't assume that applications won't leave junk in the non-standard bits of the flags when they call SendInput() or keybd_event(). This needs to be implemented entirely within the X11 driver. It needs to properly translate your X11 keyboard layout into Win32 behavior. If the problem is that AltGr is mapping to VK_MENU, and thus causing key events to generate WM_SYSKEYDOWN/UP and not go through translation, then you need to make AltGr not map to VK_MENU. Although you really need to test that on Windows. My understanding is that AltGr appears to Windows apps as Alt+Control. In any case, I know that, on Mac OS X, the Option key is used similarly to AltGr. It accesses additional characters from the keyboard layout. This works when Option is configured in the X keymap to generate XK_Mode_switch. It requires no changes to Wine. So perhaps the right approach is to make XK_ISO_Level3_Shift and XK_ISO_Group_Shift behave the same way as XK_Mode_switch. (You could also just change your X keymap to actually map the key to XK_Mode_switch.) -Ken

July 1, 2013

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Hin-Tak Leung

--- On Mon, 1/7/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: ... I hope your negative > attitude > toward the Cygwin toolchain is not typical of such > developers. After > all, even though the Windows GNU toolchain code bases have > diverged > between the two groups of developers, there is still a > common interest > between MinGW and Cygwin developers regarding getting the > GNU > toolchain to work properly on Windows. ... Look. You have been advised a few times, that it is possible and even easy to bypass installation-related problems and been given brief instructions on how to do so; you have also been told, *many times*, and *by the cygwin developers*, that you are just encounter one problems out of many, and there are more problems to come, in the thread you posted to the cygwin mailing list. Going personal and accusing others of being biased is not a way of getting help. If you have bothered to look it up as you claim to do, while I have a formal association with mingw, I have made absolutely no contribution to mingw at all, ever; whereas I have made some patches available, etc to cygwin's GNU findutils (merged into coreutils eventually), LaTeX, emacs/xemacs, over a decade ago. My history with cygwin is about twice as old as my association with mingw. That's a matter of public record. If you bother to look further, the main reason is really that cygwin is a commercial entity - part of Redhat now, but was a privately-own company until 13 years ago when Redhat acquired part of it. Formal membership to cygwin has always been different from how formal membership to mingw operates, for that very reason; and that I live locally to where that company was, (and the part of cygwin that Redhat choose not to buy, still is), and probably know or have met some of the cygwin developers in person. I don't have the fortune to meet/know many, but they have my respects. The cygwin people would have told you the exact same thing: running mingw on wine is fair easier and more straight-forward, and there are very simple technical reasons why that is the case; and that cygwin is not mingw, and there are important difference where wine is concerned. You seem to assume the difference between cygwin and mingw is small - they are not, and really a world apart, as far as wine is concerned. Going via exaggeration/sensationalist ("showstoppers") or personal attack is not going to win you any help. FWIW, on the latter point, few are interested in reading a 20-line introduction about your life (or lack of it) every time at the bottom of your posts. That's another thing that put people off from helping you.

July 1, 2013

Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Peter Rosin

On 2013-06-28 23:37, Hin-Tak Leung wrote: > --- On Fri, 28/6/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > > ... However, because of the Cygwin fork >> bug, Cygwin on >> Wine has largely been untested for the last three years so >> this could >> be a good opportunity to do such testing for the combination >> of Cygwin >> (with the fork fix) and recent Wine in case some Wine >> regression is >> discovered by such testing. > > what????!!!! You really don't get it. setup.exe is simply *not* a necessity for putting a cygwin installation under wine. There are many other ways of installing cygwin into wine without running cygwin's installer. The easiest is simply to copy the entire installed directory, plus importing a few registry entries, from a genuine windows box which has cygwin on. > > (There are many people who bundles bits of cygwin with their software for windows, for years; so if you are a full-time windows user, you might even gain some bits of cygwin without knowing it, and without ever having seen the official cygwin installer or even heard of it) . The problem is that even if you manage to put it on, many part of cygwin don't work correctly under wine. > > Please don't confuse issues with running the official installer, and issues with running the cygwin system (or part of) itself. You have been told *many times*, in that thread, that setup.exe itself does not depend on cygwin, and use no part of it. Running the official installer invokes child processes that do indeed require a functioning Cygwin DLL. I.e. post-install scripts (and pre- remove scripts, but we're talking about the initial install so that's out of scope). The registry entries you speak about are a thing of the past, if you are referring to mount points. Cheers, Peter

July 1, 2013

Mac OS X releases

by Wolf Kappesser

Hello, my name is Wolf I am from germany and use OSX 10.8 to develop my apps, play games etc. I have read that there is no one, who compile the OSX version of WINE. I would do this. I have tried the osxwinebuilder script from http://code.google.com/p/osxwinebuilder and it did the job. I have download the old 1.5.30 wine for Mac and it has some additional features. They doesn't exist in the pure osxwinebuilder build. Where I can get them? I would give the OSX wine to the community, what I need to to? I have read that I should post to this list to get additional advices. Greets Wolf

July 1, 2013

[PATCH v7 7/7] locks: Disable LOCK_MAND support for MS_SHARELOCK mounts

by Pavel Shilovsky

Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/locks.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/locks.c b/fs/locks.c index 60f3ce8..86f3a93 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -1758,6 +1758,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, cmd) goto out; } + /* Disable LOCK_MAND support for FS mounted with MS_SHARELOCK */ + if ((cmd & LOCK_MAND) && IS_SHARELOCK(f.file->f_path.dentry->d_inode)) { + error = -EPERM; + goto out; + } + can_sleep = !(cmd & LOCK_NB); cmd &= ~LOCK_NB; unlock = (cmd == LOCK_UN); -- 1.8.1.5

July 1, 2013

[PATCH v7 6/7] NFSD: Pass share reservations flags to VFS

by Pavel Shilovsky

that maps them into O_DENY* flags and make them visible for applications on mounts with sharelock option. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/locks.c | 1 + fs/nfsd/nfs4state.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- fs/nfsd/nfsproc.c | 1 + 3 files changed, 47 insertions(+), 1 deletion(-) diff --git a/fs/locks.c b/fs/locks.c index 09c1d0e..60f3ce8 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -899,6 +899,7 @@ sharelock_lock_file(struct file *filp) locks_free_lock(lock); return error; } +EXPORT_SYMBOL(sharelock_lock_file); static int __posix_lock_file(struct inode *inode, struct file_lock *request, struct file_lock *conflock) { diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index f9a5e62..b19cb3a 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -457,6 +457,19 @@ test_deny(u32 access, struct nfs4_ol_stateid *stp) return test_bit(access, &stp->st_deny_bmap); } +static int nfs4_deny_to_odeny(u32 access) +{ + switch (access & NFS4_SHARE_DENY_BOTH) { + case NFS4_SHARE_DENY_READ: + return O_DENYREAD; + case NFS4_SHARE_DENY_WRITE: + return O_DENYWRITE; + case NFS4_SHARE_DENY_BOTH: + return O_DENYREAD | O_DENYWRITE; + } + return 0; +} + static int nfs4_access_to_omode(u32 access) { switch (access & NFS4_SHARE_ACCESS_BOTH) { @@ -2780,6 +2793,21 @@ nfsd4_truncate(struct svc_rqst *rqstp, struct svc_fh *fh, } static __be32 +nfs4_vfs_set_deny(struct nfs4_file *fp, unsigned long share_access, + unsigned long deny_access) +{ + int oflag, rc; + __be32 status = nfs_ok; + + oflag = nfs4_access_to_omode(share_access); + fp->fi_fds[oflag]->f_flags |= nfs4_deny_to_odeny(deny_access); + rc = sharelock_lock_file(fp->fi_fds[oflag]); + if (rc) + status = nfserrno(rc); + return status; +} + +static __be32 nfs4_upgrade_open(struct svc_rqst *rqstp, struct nfs4_file *fp, struct svc_fh *cur_fh, struct nfs4_ol_stateid *stp, struct nfsd4_open *open) { u32 op_share_access = open->op_share_access; @@ -2800,6 +2828,14 @@ nfs4_upgrade_open(struct svc_rqst *rqstp, struct nfs4_file *fp, struct svc_fh *c } return status; } + status = nfs4_vfs_set_deny(fp, op_share_access, open->op_share_deny); + if (status) { + if (new_access) { + int oflag = nfs4_access_to_omode(op_share_access); + nfs4_file_put_access(fp, oflag); + } + return status; + } /* remember the open */ set_access(op_share_access, stp); set_deny(open->op_share_deny, stp); @@ -3033,7 +3069,7 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nf /* * OPEN the file, or upgrade an existing OPEN. - * If truncate fails, the OPEN fails. + * If truncate or set_deny fails, the OPEN fails. */ if (stp) { /* Stateid was found, this is an OPEN upgrade */ @@ -3047,6 +3083,10 @@ nfsd4_process_open2(struct svc_rqst *rqstp, struct svc_fh *current_fh, struct nf status = nfsd4_truncate(rqstp, current_fh, open); if (status) goto out; + status = nfs4_vfs_set_deny(fp, open->op_share_access, + open->op_share_deny); + if (status) + goto out; stp = open->op_stp; open->op_stp = NULL; init_open_stateid(stp, fp, open); @@ -3745,6 +3785,10 @@ nfsd4_open_downgrade(struct svc_rqst *rqstp, } nfs4_stateid_downgrade(stp, od->od_share_access); + status = nfs4_vfs_set_deny(stp->st_file, od->od_share_access, + od->od_share_deny); + if (status) + goto out; reset_union_bmap_deny(od->od_share_deny, stp); update_stateid(&stp->st_stid.sc_stateid); diff --git a/fs/nfsd/nfsproc.c b/fs/nfsd/nfsproc.c index 54c6b3d..ff95544 100644 --- a/fs/nfsd/nfsproc.c +++ b/fs/nfsd/nfsproc.c @@ -743,6 +743,7 @@ nfserrno (int errno) { nfserr_notsupp, -EOPNOTSUPP }, { nfserr_toosmall, -ETOOSMALL }, { nfserr_serverfault, -ESERVERFAULT }, + { nfserr_share_denied, -ESHAREDENIED }, }; int i; -- 1.8.1.5

July 1, 2013

[PATCH v7 5/7] NFSv4: Add O_DENY* open flags support

by Pavel Shilovsky

by passing these flags to NFSv4 open request. Make it return -ESHAREDENIED on share conflicts with other opens and disable O_DENYDELETE support since NFSv4 doesn't support it. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/nfs/dir.c | 4 ++++ fs/nfs/internal.h | 3 ++- fs/nfs/nfs4file.c | 4 ++++ fs/nfs/nfs4proc.c | 4 +++- fs/nfs/nfs4super.c | 9 ++++++--- fs/nfs/nfs4xdr.c | 21 +++++++++++++++++---- fs/nfs/super.c | 6 +++++- 7 files changed, 41 insertions(+), 10 deletions(-) diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index f23f455..fe3215c 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1395,6 +1395,10 @@ int nfs_atomic_open(struct inode *dir, struct dentry *dentry, dfprintk(VFS, "NFS: atomic_open(%s/%ld), %s\n", dir->i_sb->s_id, dir->i_ino, dentry->d_name.name); + /* No support for O_DENYDELETE */ + if (open_flags & O_DENYDELETE) + return -EINVAL; + /* NFS only supports OPEN on regular files */ if ((open_flags & O_DIRECTORY)) { if (!d_unhashed(dentry)) { diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h index 541c9eb..70cd1b0 100644 --- a/fs/nfs/internal.h +++ b/fs/nfs/internal.h @@ -6,7 +6,8 @@ #include <linux/mount.h> #include <linux/security.h> -#define NFS_MS_MASK (MS_RDONLY|MS_NOSUID|MS_NODEV|MS_NOEXEC|MS_SYNCHRONOUS) +#define NFS_MS_MASK (MS_RDONLY | MS_NOSUID | MS_NODEV | MS_NOEXEC | \ + MS_SYNCHRONOUS | MS_SHARELOCK) struct nfs_string; diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c index 13e6bb3..f5ec400 100644 --- a/fs/nfs/nfs4file.c +++ b/fs/nfs/nfs4file.c @@ -34,6 +34,10 @@ nfs4_file_open(struct inode *inode, struct file *filp) dentry->d_parent->d_name.name, dentry->d_name.name); + /* No support for O_DENYDELETE */ + if (openflags & O_DENYDELETE) + return -EINVAL; + if ((openflags & O_ACCMODE) == 3) openflags--; diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 261e9b9..6eabd2a 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -102,7 +102,7 @@ static int nfs4_map_errors(int err) case -NFS4ERR_BADNAME: return -EINVAL; case -NFS4ERR_SHARE_DENIED: - return -EACCES; + return -ESHAREDENIED; case -NFS4ERR_MINOR_VERS_MISMATCH: return -EPROTONOSUPPORT; case -NFS4ERR_ACCESS: @@ -795,6 +795,8 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry, atomic_inc(&sp->so_count); p->o_arg.fh = NFS_FH(dir); p->o_arg.open_flags = flags; + if (!IS_SHARELOCK(dir)) + p->o_arg.open_flags &= ~(O_DENYREAD | O_DENYWRITE); p->o_arg.fmode = fmode & (FMODE_READ|FMODE_WRITE); /* don't put an ACCESS op in OPEN compound if O_EXCL, because ACCESS * will return permission denied for all bits until close */ diff --git a/fs/nfs/nfs4super.c b/fs/nfs/nfs4super.c index 569b166..a25a929 100644 --- a/fs/nfs/nfs4super.c +++ b/fs/nfs/nfs4super.c @@ -28,7 +28,8 @@ static struct file_system_type nfs4_remote_fs_type = { .name = "nfs4", .mount = nfs4_remote_mount, .kill_sb = nfs_kill_super, - .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, + .fs_flags = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA | + FS_DOES_SHARELOCK, }; static struct file_system_type nfs4_remote_referral_fs_type = { @@ -36,7 +37,8 @@ static struct file_system_type nfs4_remote_referral_fs_type = { .name = "nfs4", .mount = nfs4_remote_referral_mount, .kill_sb = nfs_kill_super, - .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, + .fs_flags = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA | + FS_DOES_SHARELOCK, }; struct file_system_type nfs4_referral_fs_type = { @@ -44,7 +46,8 @@ struct file_system_type nfs4_referral_fs_type = { .name = "nfs4", .mount = nfs4_referral_mount, .kill_sb = nfs_kill_super, - .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, + .fs_flags = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA | + FS_DOES_SHARELOCK, }; static const struct super_operations nfs4_sops = { diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c index e3edda5..cb0e8de 100644 --- a/fs/nfs/nfs4xdr.c +++ b/fs/nfs/nfs4xdr.c @@ -1325,7 +1325,8 @@ static void encode_lookup(struct xdr_stream *xdr, const struct qstr *name, struc encode_string(xdr, name->len, name->name); } -static void encode_share_access(struct xdr_stream *xdr, fmode_t fmode) +static void encode_share_access(struct xdr_stream *xdr, fmode_t fmode, + int open_flags) { __be32 *p; @@ -1343,7 +1344,19 @@ static void encode_share_access(struct xdr_stream *xdr, fmode_t fmode) default: *p++ = cpu_to_be32(0); } - *p = cpu_to_be32(0); /* for linux, share_deny = 0 always */ + switch (open_flags & (O_DENYREAD|O_DENYWRITE)) { + case O_DENYREAD: + *p = cpu_to_be32(NFS4_SHARE_DENY_READ); + break; + case O_DENYWRITE: + *p = cpu_to_be32(NFS4_SHARE_DENY_WRITE); + break; + case O_DENYREAD|O_DENYWRITE: + *p = cpu_to_be32(NFS4_SHARE_DENY_BOTH); + break; + default: + *p = cpu_to_be32(0); + } } static inline void encode_openhdr(struct xdr_stream *xdr, const struct nfs_openargs *arg) @@ -1354,7 +1367,7 @@ static inline void encode_openhdr(struct xdr_stream *xdr, const struct nfs_opena * owner 4 = 32 */ encode_nfs4_seqid(xdr, arg->seqid); - encode_share_access(xdr, arg->fmode); + encode_share_access(xdr, arg->fmode, arg->open_flags); p = reserve_space(xdr, 36); p = xdr_encode_hyper(p, arg->clientid); *p++ = cpu_to_be32(24); @@ -1491,7 +1504,7 @@ static void encode_open_downgrade(struct xdr_stream *xdr, const struct nfs_close encode_op_hdr(xdr, OP_OPEN_DOWNGRADE, decode_open_downgrade_maxsz, hdr); encode_nfs4_stateid(xdr, arg->stateid); encode_nfs4_seqid(xdr, arg->seqid); - encode_share_access(xdr, arg->fmode); + encode_share_access(xdr, arg->fmode, 0); } static void diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 2f8a29d..3ba828b 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -333,6 +333,8 @@ struct file_system_type nfs4_fs_type = { .mount = nfs_fs_mount, .kill_sb = nfs_kill_super, .fs_flags = FS_RENAME_DOES_D_MOVE|FS_BINARY_MOUNTDATA, + .fs_flags = FS_RENAME_DOES_D_MOVE | FS_BINARY_MOUNTDATA | + FS_DOES_SHARELOCK, }; MODULE_ALIAS_FS("nfs4"); MODULE_ALIAS("nfs4"); @@ -2544,6 +2546,8 @@ nfs_xdev_mount(struct file_system_type *fs_type, int flags, struct nfs_server *server; struct dentry *mntroot = ERR_PTR(-ENOMEM); struct nfs_subversion *nfs_mod = NFS_SB(data->sb)->nfs_client->cl_nfs_mod; + /* save sharelock option */ + int sharelock = data->sb->s_flags & MS_SHARELOCK; dprintk("--> nfs_xdev_mount()\n"); @@ -2555,7 +2559,7 @@ nfs_xdev_mount(struct file_system_type *fs_type, int flags, if (IS_ERR(server)) mntroot = ERR_CAST(server); else - mntroot = nfs_fs_mount_common(server, flags, + mntroot = nfs_fs_mount_common(server, flags | sharelock, dev_name, &mount_info, nfs_mod); dprintk("<-- nfs_xdev_mount() = %ld\n", -- 1.8.1.5

July 1, 2013

[PATCH v7 4/7] CIFS: Add O_DENY* open flags support

by Pavel Shilovsky

Construct share_access value from O_DENY* flags and send it to the server. Use NTCreateAndX command rather than Trans2 all the time we have any of O_DENY* flags regardless of unix extensions support. Also change smb error mapping of NT_STATUS_SHARING_VIOLATION to -ESHAREDENIED. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/cifs/cifsfs.c | 2 +- fs/cifs/cifsglob.h | 16 +++++++++++++++- fs/cifs/dir.c | 4 ++++ fs/cifs/file.c | 15 +++++++++++++-- fs/cifs/inode.c | 5 +++-- fs/cifs/netmisc.c | 2 +- fs/cifs/smb2maperror.c | 2 +- fs/locks.c | 11 ++++++++++- include/linux/fs.h | 1 + 9 files changed, 49 insertions(+), 9 deletions(-) diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 345fc89..92bd685 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -799,7 +799,7 @@ struct file_system_type cifs_fs_type = { .name = "cifs", .mount = cifs_do_mount, .kill_sb = cifs_kill_sb, - /* .fs_flags */ + .fs_flags = FS_DOES_SHARELOCK, }; MODULE_ALIAS_FS("cifs"); const struct inode_operations cifs_dir_inode_ops = { diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 80af61d..85703f6 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -465,7 +465,7 @@ struct smb_vol { CIFS_MOUNT_CIFS_BACKUPUID | CIFS_MOUNT_CIFS_BACKUPGID) #define CIFS_MS_MASK (MS_RDONLY | MS_MANDLOCK | MS_NOEXEC | MS_NOSUID | \ - MS_NODEV | MS_SYNCHRONOUS) + MS_NODEV | MS_SYNCHRONOUS | MS_SHARELOCK) struct cifs_mnt_data { struct cifs_sb_info *cifs_sb; @@ -947,6 +947,20 @@ struct cifsFileInfo { struct work_struct oplock_break; /* work for oplock breaks */ }; +static inline int +cifs_get_share_flags(unsigned int flags) +{ + int share_access = 0; + + if (!(flags & O_DENYREAD)) + share_access |= FILE_SHARE_READ; + if (!(flags & O_DENYWRITE)) + share_access |= FILE_SHARE_WRITE; + if (!(flags & O_DENYDELETE)) + share_access |= FILE_SHARE_DELETE; + return share_access; +} + struct cifs_io_parms { __u16 netfid; #ifdef CONFIG_CIFS_SMB2 diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c index e5f6723..c03ad8c 100644 --- a/fs/cifs/dir.c +++ b/fs/cifs/dir.c @@ -216,7 +216,11 @@ cifs_do_create(struct inode *inode, struct dentry *direntry, unsigned int xid, goto out; } + if (IS_SHARELOCK(inode)) + share_access = cifs_get_share_flags(oflags); + if (tcon->unix_ext && cap_unix(tcon->ses) && !tcon->broken_posix_open && + (share_access == FILE_SHARE_ALL) && (CIFS_UNIX_POSIX_PATH_OPS_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability))) { rc = cifs_posix_open(full_path, &newinode, inode->i_sb, mode, diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 7631b0c..febf807 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -216,6 +216,8 @@ cifs_nt_open(char *full_path, struct inode *inode, struct cifs_sb_info *cifs_sb, *********************************************************************/ disposition = cifs_get_disposition(f_flags); + if (IS_SHARELOCK(inode)) + share_access = cifs_get_share_flags(f_flags); /* BB pass O_SYNC flag through on file attributes .. BB */ @@ -428,6 +430,7 @@ int cifs_open(struct inode *inode, struct file *file) int rc = -EACCES; unsigned int xid; __u32 oplock; + int share_access = FILE_SHARE_ALL; struct cifs_sb_info *cifs_sb; struct TCP_Server_Info *server; struct cifs_tcon *tcon; @@ -463,8 +466,12 @@ int cifs_open(struct inode *inode, struct file *file) else oplock = 0; - if (!tcon->broken_posix_open && tcon->unix_ext && - cap_unix(tcon->ses) && (CIFS_UNIX_POSIX_PATH_OPS_CAP & + if (IS_SHARELOCK(inode)) + share_access = cifs_get_share_flags(file->f_flags); + + if (!tcon->broken_posix_open && tcon->unix_ext && cap_unix(tcon->ses) && + (share_access == FILE_SHARE_ALL) && + (CIFS_UNIX_POSIX_PATH_OPS_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability))) { /* can not refresh inode info since size could be stale */ rc = cifs_posix_open(full_path, &inode, inode->i_sb, @@ -631,7 +638,11 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush) else oplock = 0; + if (IS_SHARELOCK(inode)) + share_access = cifs_get_share_flags(cfile->f_flags); + if (tcon->unix_ext && cap_unix(tcon->ses) && + (share_access == FILE_SHARE_ALL) && (CIFS_UNIX_POSIX_PATH_OPS_CAP & le64_to_cpu(tcon->fsUnixInfo.Capability))) { /* diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index 039d9a1..7aed606 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -1167,7 +1167,8 @@ psx_del_no_retry: cifs_drop_nlink(inode); } else if (rc == -ENOENT) { d_drop(dentry); - } else if (rc == -EBUSY) { + } else if (rc == -ESHAREDENIED) { + rc = -EBUSY; if (server->ops->rename_pending_delete) { rc = server->ops->rename_pending_delete(full_path, dentry, xid); @@ -1514,7 +1515,7 @@ cifs_do_rename(const unsigned int xid, struct dentry *from_dentry, * source. Note that cross directory moves do not work with * rename by filehandle to various Windows servers. */ - if (rc == 0 || rc != -EBUSY) + if (rc == 0 || rc != -ESHAREDENIED) goto do_rename_exit; /* open-file renames don't work across directories */ diff --git a/fs/cifs/netmisc.c b/fs/cifs/netmisc.c index c0b25b2..a9c8bef 100644 --- a/fs/cifs/netmisc.c +++ b/fs/cifs/netmisc.c @@ -62,7 +62,7 @@ static const struct smb_to_posix_error mapping_table_ERRDOS[] = { {ERRdiffdevice, -EXDEV}, {ERRnofiles, -ENOENT}, {ERRwriteprot, -EROFS}, - {ERRbadshare, -EBUSY}, + {ERRbadshare, -ESHAREDENIED}, {ERRlock, -EACCES}, {ERRunsup, -EINVAL}, {ERRnosuchshare, -ENXIO}, diff --git a/fs/cifs/smb2maperror.c b/fs/cifs/smb2maperror.c index 494c912..d70b6ca 100644 --- a/fs/cifs/smb2maperror.c +++ b/fs/cifs/smb2maperror.c @@ -356,7 +356,7 @@ static const struct status_to_posix_error smb2_error_map_table[] = { {STATUS_PORT_CONNECTION_REFUSED, -ECONNREFUSED, "STATUS_PORT_CONNECTION_REFUSED"}, {STATUS_INVALID_PORT_HANDLE, -EIO, "STATUS_INVALID_PORT_HANDLE"}, - {STATUS_SHARING_VIOLATION, -EBUSY, "STATUS_SHARING_VIOLATION"}, + {STATUS_SHARING_VIOLATION, -ESHAREDENIED, "STATUS_SHARING_VIOLATION"}, {STATUS_QUOTA_EXCEEDED, -EDQUOT, "STATUS_QUOTA_EXCEEDED"}, {STATUS_INVALID_PAGE_PROTECTION, -EIO, "STATUS_INVALID_PAGE_PROTECTION"}, diff --git a/fs/locks.c b/fs/locks.c index c2fa136..09c1d0e 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -847,6 +847,10 @@ sharelock_may_delete(struct dentry *dentry) if (!IS_SHARELOCK(dentry->d_inode)) return rc; + /* Don't check a lock on file systems that do it internally */ + if (dentry->d_inode->i_sb->s_type->fs_flags & FS_DOES_SHARELOCK) + return rc; + lock_flocks(); for_each_lock(dentry->d_inode, before) { struct file_lock *fl = *before; @@ -875,8 +879,13 @@ sharelock_lock_file(struct file *filp) { struct file_lock *lock; int error = 0; + struct inode *inode = filp->f_path.dentry->d_inode; + + if (!IS_SHARELOCK(inode)) + return error; - if (!IS_SHARELOCK(filp->f_path.dentry->d_inode)) + /* Don't set a lock on file systems that do it internally */ + if (inode->i_sb->s_type->fs_flags & FS_DOES_SHARELOCK) return error; error = flock_make_lock(filp, &lock, deny_flags_to_cmd(filp->f_flags)); diff --git a/include/linux/fs.h b/include/linux/fs.h index 3247fb4..f802776b 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1821,6 +1821,7 @@ struct file_system_type { #define FS_USERNS_MOUNT 8 /* Can be mounted by userns root */ #define FS_USERNS_DEV_MOUNT 16 /* A userns mount does not imply MNT_NODEV */ #define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move() during rename() internally. */ +#define FS_DOES_SHARELOCK 65536 /* FS does sharelocks internally */ struct dentry *(*mount) (struct file_system_type *, int, const char *, void *); void (*kill_sb) (struct super_block *); -- 1.8.1.5

July 1, 2013

[PATCH v7 3/7] CIFS: Add share_access parm to open request

by Pavel Shilovsky

and simplify CIFSSMBOpen params. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/cifs/cifsacl.c | 8 ++++---- fs/cifs/cifsglob.h | 2 +- fs/cifs/cifsproto.h | 8 ++++---- fs/cifs/cifssmb.c | 50 +++++++++++++++++++++++++++----------------------- fs/cifs/dir.c | 12 ++++++------ fs/cifs/file.c | 10 ++++++---- fs/cifs/inode.c | 16 ++++++---------- fs/cifs/link.c | 25 ++++++++----------------- fs/cifs/readdir.c | 5 ++--- fs/cifs/smb1ops.c | 16 +++++++--------- fs/cifs/smb2file.c | 10 +++++----- fs/cifs/smb2inode.c | 4 ++-- fs/cifs/smb2ops.c | 10 ++++++---- fs/cifs/smb2pdu.c | 6 +++--- fs/cifs/smb2proto.h | 14 ++++++++------ 15 files changed, 95 insertions(+), 101 deletions(-) diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c index f1e3f25..56bdae2 100644 --- a/fs/cifs/cifsacl.c +++ b/fs/cifs/cifsacl.c @@ -908,8 +908,8 @@ static struct cifs_ntsd *get_cifs_acl_by_path(struct cifs_sb_info *cifs_sb, create_options |= CREATE_OPEN_BACKUP_INTENT; rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, READ_CONTROL, - create_options, &fid, &oplock, NULL, cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, create_options, &fid, &oplock, + NULL, cifs_sb); if (!rc) { rc = CIFSSMBGetCIFSACL(xid, tcon, fid, &pntsd, pacllen); CIFSSMBClose(xid, tcon, fid); @@ -969,8 +969,8 @@ int set_cifs_acl(struct cifs_ntsd *pnntsd, __u32 acllen, access_flags = WRITE_DAC; rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, access_flags, - create_options, &fid, &oplock, NULL, cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, create_options, &fid, &oplock, + NULL, cifs_sb); if (rc) { cERROR(1, "Unable to open file to set ACL"); goto out; diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h index 4f07f6f..80af61d 100644 --- a/fs/cifs/cifsglob.h +++ b/fs/cifs/cifsglob.h @@ -310,7 +310,7 @@ struct smb_version_operations { struct cifs_sb_info *); /* open a file for non-posix mounts */ int (*open)(const unsigned int, struct cifs_tcon *, const char *, int, - int, int, struct cifs_fid *, __u32 *, FILE_ALL_INFO *, + int, int, int, struct cifs_fid *, __u32 *, FILE_ALL_INFO *, struct cifs_sb_info *); /* set fid protocol-specific info */ void (*set_fid)(struct cifsFileInfo *, struct cifs_fid *, __u32); diff --git a/fs/cifs/cifsproto.h b/fs/cifs/cifsproto.h index f450f06..d285b81 100644 --- a/fs/cifs/cifsproto.h +++ b/fs/cifs/cifsproto.h @@ -362,10 +362,10 @@ extern int CIFSSMBQueryReparseLinkInfo(const unsigned int xid, const struct nls_table *nls_codepage); #endif /* temporarily unused until cifs_symlink fixed */ extern int CIFSSMBOpen(const unsigned int xid, struct cifs_tcon *tcon, - const char *fileName, const int disposition, - const int access_flags, const int omode, - __u16 *netfid, int *pOplock, FILE_ALL_INFO *, - const struct nls_table *nls_codepage, int remap); + const char *file_name, const int disposition, + const int desired_access, const int share_access, + const int omode, __u16 *netfid, int *oplock, + FILE_ALL_INFO *, struct cifs_sb_info *); extern int SMBLegacyOpen(const unsigned int xid, struct cifs_tcon *tcon, const char *fileName, const int disposition, const int access_flags, const int omode, diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c index 8e2e799..c857b02 100644 --- a/fs/cifs/cifssmb.c +++ b/fs/cifs/cifssmb.c @@ -1289,10 +1289,10 @@ OldOpenRetry: int CIFSSMBOpen(const unsigned int xid, struct cifs_tcon *tcon, - const char *fileName, const int openDisposition, - const int access_flags, const int create_options, __u16 *netfid, - int *pOplock, FILE_ALL_INFO *pfile_info, - const struct nls_table *nls_codepage, int remap) + const char *file_name, const int disposition, + const int desired_access, const int share_access, + const int create_options, __u16 *netfid, int *oplock, + FILE_ALL_INFO *file_info, struct cifs_sb_info *cifs_sb) { int rc = -EACCES; OPEN_REQ *pSMB = NULL; @@ -1300,6 +1300,8 @@ CIFSSMBOpen(const unsigned int xid, struct cifs_tcon *tcon, int bytes_returned; int name_len; __u16 count; + struct nls_table *nls_codepage = cifs_sb->local_nls; + int remap = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR; openRetry: rc = smb_init(SMB_COM_NT_CREATE_ANDX, 24, tcon, (void **) &pSMB, @@ -1313,26 +1315,28 @@ openRetry: count = 1; /* account for one byte pad to word boundary */ name_len = cifsConvertToUTF16((__le16 *) (pSMB->fileName + 1), - fileName, PATH_MAX, nls_codepage, remap); + file_name, PATH_MAX, nls_codepage, + remap); name_len++; /* trailing null */ name_len *= 2; pSMB->NameLength = cpu_to_le16(name_len); } else { /* BB improve check for buffer overruns BB */ count = 0; /* no pad */ - name_len = strnlen(fileName, PATH_MAX); + name_len = strnlen(file_name, PATH_MAX); name_len++; /* trailing null */ pSMB->NameLength = cpu_to_le16(name_len); - strncpy(pSMB->fileName, fileName, name_len); + strncpy(pSMB->fileName, file_name, name_len); } - if (*pOplock & REQ_OPLOCK) + if (*oplock & REQ_OPLOCK) pSMB->OpenFlags = cpu_to_le32(REQ_OPLOCK); - else if (*pOplock & REQ_BATCHOPLOCK) + else if (*oplock & REQ_BATCHOPLOCK) pSMB->OpenFlags = cpu_to_le32(REQ_BATCHOPLOCK); - pSMB->DesiredAccess = cpu_to_le32(access_flags); + pSMB->DesiredAccess = cpu_to_le32(desired_access); pSMB->AllocationSize = 0; - /* set file as system file if special file such - as fifo and server expecting SFU style and - no Unix extensions */ + /* + * set file as system file if special file such as fifo and server + * expecting SFU style and no Unix extensions + */ if (create_options & CREATE_OPTION_SPECIAL) pSMB->FileAttributes = cpu_to_le32(ATTR_SYSTEM); else @@ -1347,8 +1351,8 @@ openRetry: if (create_options & CREATE_OPTION_READONLY) pSMB->FileAttributes |= cpu_to_le32(ATTR_READONLY); - pSMB->ShareAccess = cpu_to_le32(FILE_SHARE_ALL); - pSMB->CreateDisposition = cpu_to_le32(openDisposition); + pSMB->ShareAccess = cpu_to_le32(share_access); + pSMB->CreateDisposition = cpu_to_le32(disposition); pSMB->CreateOptions = cpu_to_le32(create_options & CREATE_OPTIONS_MASK); /* BB Expirement with various impersonation levels and verify */ pSMB->ImpersonationLevel = cpu_to_le32(SECURITY_IMPERSONATION); @@ -1366,20 +1370,20 @@ openRetry: if (rc) { cFYI(1, "Error in Open = %d", rc); } else { - *pOplock = pSMBr->OplockLevel; /* 1 byte no need to le_to_cpu */ + *oplock = pSMBr->OplockLevel; /* 1 byte no need to le_to_cpu */ *netfid = pSMBr->Fid; /* cifs fid stays in le */ /* Let caller know file was created so we can set the mode. */ /* Do we care about the CreateAction in any other cases? */ if (cpu_to_le32(FILE_CREATE) == pSMBr->CreateAction) - *pOplock |= CIFS_CREATE_ACTION; - if (pfile_info) { - memcpy((char *)pfile_info, (char *)&pSMBr->CreationTime, + *oplock |= CIFS_CREATE_ACTION; + if (file_info) { + memcpy((char *)file_info, (char *)&pSMBr->CreationTime, 36 /* CreationTime to Attributes */); /* the file_info buf is endian converted by caller */ - pfile_info->AllocationSize = pSMBr->AllocationSize; - pfile_info->EndOfFile = pSMBr->EndOfFile; - pfile_info->NumberOfLinks = cpu_to_le32(1); - pfile_info->DeletePending = 0; + file_info->AllocationSize = pSMBr->AllocationSize; + file_info->EndOfFile = pSMBr->EndOfFile; + file_info->NumberOfLinks = cpu_to_le32(1); + file_info->DeletePending = 0; } } diff --git a/fs/cifs/dir.c b/fs/cifs/dir.c index 1cd0162..e5f6723 100644 --- a/fs/cifs/dir.c +++ b/fs/cifs/dir.c @@ -203,6 +203,7 @@ cifs_do_create(struct inode *inode, struct dentry *direntry, unsigned int xid, FILE_ALL_INFO *buf = NULL; struct inode *newinode = NULL; int disposition; + int share_access = FILE_SHARE_ALL; struct TCP_Server_Info *server = tcon->ses->server; *oplock = 0; @@ -320,8 +321,8 @@ cifs_do_create(struct inode *inode, struct dentry *direntry, unsigned int xid, create_options |= CREATE_OPEN_BACKUP_INTENT; rc = server->ops->open(xid, tcon, full_path, disposition, - desired_access, create_options, fid, oplock, - buf, cifs_sb); + desired_access, share_access, create_options, + fid, oplock, buf, cifs_sb); if (rc) { cFYI(1, "cifs_create returned 0x%x", rc); goto out; @@ -626,10 +627,9 @@ int cifs_mknod(struct inode *inode, struct dentry *direntry, umode_t mode, if (backup_cred(cifs_sb)) create_options |= CREATE_OPEN_BACKUP_INTENT; - rc = CIFSSMBOpen(xid, pTcon, full_path, FILE_CREATE, - GENERIC_WRITE, create_options, - &fileHandle, &oplock, buf, cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + rc = CIFSSMBOpen(xid, pTcon, full_path, FILE_CREATE, GENERIC_WRITE, + FILE_SHARE_ALL, create_options, &fileHandle, &oplock, + buf, cifs_sb); if (rc) goto mknod_out; diff --git a/fs/cifs/file.c b/fs/cifs/file.c index 7a0dd99..7631b0c 100644 --- a/fs/cifs/file.c +++ b/fs/cifs/file.c @@ -180,6 +180,7 @@ cifs_nt_open(char *full_path, struct inode *inode, struct cifs_sb_info *cifs_sb, { int rc; int desired_access; + int share_access = FILE_SHARE_ALL; int disposition; int create_options = CREATE_NOT_DIR; FILE_ALL_INFO *buf; @@ -226,8 +227,8 @@ cifs_nt_open(char *full_path, struct inode *inode, struct cifs_sb_info *cifs_sb, create_options |= CREATE_OPEN_BACKUP_INTENT; rc = server->ops->open(xid, tcon, full_path, disposition, - desired_access, create_options, fid, oplock, buf, - cifs_sb); + desired_access, share_access, create_options, + fid, oplock, buf, cifs_sb); if (rc) goto out; @@ -589,6 +590,7 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush) struct inode *inode; char *full_path = NULL; int desired_access; + int share_access = FILE_SHARE_ALL; int disposition = FILE_OPEN; int create_options = CREATE_NOT_DIR; struct cifs_fid fid; @@ -668,8 +670,8 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush) * not dirty locally we could do this. */ rc = server->ops->open(xid, tcon, full_path, disposition, - desired_access, create_options, &fid, &oplock, - NULL, cifs_sb); + desired_access, share_access, create_options, + &fid, &oplock, NULL, cifs_sb); if (rc) { mutex_unlock(&cfile->fh_mutex); cFYI(1, "cifs_reopen returned 0x%x", rc); diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index cb88429..039d9a1 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -407,10 +407,8 @@ cifs_sfu_type(struct cifs_fattr *fattr, const unsigned char *path, tcon = tlink_tcon(tlink); rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, GENERIC_READ, - CREATE_NOT_DIR, &netfid, &oplock, NULL, - cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & - CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, CREATE_NOT_DIR, &netfid, &oplock, + NULL, cifs_sb); if (rc == 0) { int buf_type = CIFS_NO_BUFFER; /* Read header */ @@ -1006,9 +1004,8 @@ cifs_rename_pending_delete(const char *full_path, struct dentry *dentry, } rc = CIFSSMBOpen(xid, tcon, full_path, FILE_OPEN, - DELETE|FILE_WRITE_ATTRIBUTES, CREATE_NOT_DIR, - &netfid, &oplock, NULL, cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + DELETE|FILE_WRITE_ATTRIBUTES, FILE_SHARE_ALL, + CREATE_NOT_DIR, &netfid, &oplock, NULL, cifs_sb); if (rc != 0) goto out; @@ -1526,9 +1523,8 @@ cifs_do_rename(const unsigned int xid, struct dentry *from_dentry, /* open the file to be renamed -- we need DELETE perms */ rc = CIFSSMBOpen(xid, tcon, from_path, FILE_OPEN, DELETE, - CREATE_NOT_DIR, &srcfid, &oplock, NULL, - cifs_sb->local_nls, cifs_sb->mnt_cifs_flags & - CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, CREATE_NOT_DIR, &srcfid, &oplock, NULL, + cifs_sb); if (rc == 0) { rc = CIFSSMBRenameOpenFile(xid, tcon, srcfid, (const char *) to_dentry->d_name.name, diff --git a/fs/cifs/link.c b/fs/cifs/link.c index 9f6c4c4..886f61d 100644 --- a/fs/cifs/link.c +++ b/fs/cifs/link.c @@ -187,16 +187,11 @@ CIFSCreateMFSymLink(const unsigned int xid, struct cifs_tcon *tcon, { int rc; int oplock = 0; - int remap; int create_options = CREATE_NOT_DIR; __u16 netfid = 0; u8 *buf; unsigned int bytes_written = 0; struct cifs_io_parms io_parms; - struct nls_table *nls_codepage; - - nls_codepage = cifs_sb->local_nls; - remap = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR; buf = kmalloc(CIFS_MF_SYMLINK_FILE_SIZE, GFP_KERNEL); if (!buf) @@ -212,8 +207,8 @@ CIFSCreateMFSymLink(const unsigned int xid, struct cifs_tcon *tcon, create_options |= CREATE_OPEN_BACKUP_INTENT; rc = CIFSSMBOpen(xid, tcon, fromName, FILE_CREATE, GENERIC_WRITE, - create_options, &netfid, &oplock, NULL, - nls_codepage, remap); + FILE_SHARE_ALL, create_options, &netfid, &oplock, NULL, + cifs_sb); if (rc != 0) { kfree(buf); return rc; @@ -240,7 +235,7 @@ CIFSCreateMFSymLink(const unsigned int xid, struct cifs_tcon *tcon, static int CIFSQueryMFSymLink(const unsigned int xid, struct cifs_tcon *tcon, const unsigned char *searchName, char **symlinkinfo, - const struct nls_table *nls_codepage, int remap) + struct cifs_sb_info *cifs_sb) { int rc; int oplock = 0; @@ -254,8 +249,8 @@ CIFSQueryMFSymLink(const unsigned int xid, struct cifs_tcon *tcon, FILE_ALL_INFO file_info; rc = CIFSSMBOpen(xid, tcon, searchName, FILE_OPEN, GENERIC_READ, - CREATE_NOT_DIR, &netfid, &oplock, &file_info, - nls_codepage, remap); + FILE_SHARE_ALL, CREATE_NOT_DIR, &netfid, &oplock, + &file_info, cifs_sb); if (rc != 0) return rc; @@ -332,10 +327,8 @@ CIFSCheckMFSymlink(struct cifs_fattr *fattr, pTcon = tlink_tcon(tlink); rc = CIFSSMBOpen(xid, pTcon, path, FILE_OPEN, GENERIC_READ, - CREATE_NOT_DIR, &netfid, &oplock, &file_info, - cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & - CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, CREATE_NOT_DIR, &netfid, &oplock, + &file_info, cifs_sb); if (rc != 0) goto out; @@ -530,9 +523,7 @@ cifs_follow_link(struct dentry *direntry, struct nameidata *nd) */ if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MF_SYMLINKS) rc = CIFSQueryMFSymLink(xid, tcon, full_path, &target_path, - cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & - CIFS_MOUNT_MAP_SPECIAL_CHR); + cifs_sb); if ((rc != 0) && cap_unix(tcon->ses)) rc = CIFSSMBUnixQuerySymLink(xid, tcon, full_path, &target_path, diff --git a/fs/cifs/readdir.c b/fs/cifs/readdir.c index df40cc5..3d6717d 100644 --- a/fs/cifs/readdir.c +++ b/fs/cifs/readdir.c @@ -222,9 +222,8 @@ int get_symlink_reparse_path(char *full_path, struct cifs_sb_info *cifs_sb, char *tmpbuffer; rc = CIFSSMBOpen(xid, ptcon, full_path, FILE_OPEN, GENERIC_READ, - OPEN_REPARSE_POINT, &fid, &oplock, NULL, - cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + FILE_SHARE_ALL, OPEN_REPARSE_POINT, &fid, &oplock, NULL, + cifs_sb); if (!rc) { tmpbuffer = kmalloc(maxpath); rc = CIFSSMBQueryReparseLinkInfo(xid, ptcon, full_path, diff --git a/fs/cifs/smb1ops.c b/fs/cifs/smb1ops.c index 47bc5a8..a76950a 100644 --- a/fs/cifs/smb1ops.c +++ b/fs/cifs/smb1ops.c @@ -671,9 +671,9 @@ cifs_mkdir_setinfo(struct inode *inode, const char *full_path, static int cifs_open_file(const unsigned int xid, struct cifs_tcon *tcon, const char *path, - int disposition, int desired_access, int create_options, - struct cifs_fid *fid, __u32 *oplock, FILE_ALL_INFO *buf, - struct cifs_sb_info *cifs_sb) + int disposition, int desired_access, int share_access, + int create_options, struct cifs_fid *fid, __u32 *oplock, + FILE_ALL_INFO *buf, struct cifs_sb_info *cifs_sb) { if (!(tcon->ses->capabilities & CAP_NT_SMBS)) return SMBLegacyOpen(xid, tcon, path, disposition, @@ -682,9 +682,8 @@ cifs_open_file(const unsigned int xid, struct cifs_tcon *tcon, const char *path, cifs_sb->local_nls, cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); return CIFSSMBOpen(xid, tcon, path, disposition, desired_access, - create_options, &fid->netfid, oplock, buf, - cifs_sb->local_nls, cifs_sb->mnt_cifs_flags & - CIFS_MOUNT_MAP_SPECIAL_CHR); + share_access, create_options, &fid->netfid, oplock, + buf, cifs_sb); } static void @@ -779,9 +778,8 @@ smb_set_file_info(struct inode *inode, const char *full_path, cFYI(1, "calling SetFileInfo since SetPathInfo for times not supported " "by this server"); rc = CIFSSMBOpen(xid, tcon, full_path, FILE_OPEN, - SYNCHRONIZE | FILE_WRITE_ATTRIBUTES, CREATE_NOT_DIR, - &netfid, &oplock, NULL, cifs_sb->local_nls, - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); + SYNCHRONIZE | FILE_WRITE_ATTRIBUTES, FILE_SHARE_ALL, + CREATE_NOT_DIR, &netfid, &oplock, NULL, cifs_sb); if (rc != 0) { if (rc == -EIO) diff --git a/fs/cifs/smb2file.c b/fs/cifs/smb2file.c index 71e6aed..7dfb50c 100644 --- a/fs/cifs/smb2file.c +++ b/fs/cifs/smb2file.c @@ -58,9 +58,9 @@ smb2_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock) int smb2_open_file(const unsigned int xid, struct cifs_tcon *tcon, const char *path, - int disposition, int desired_access, int create_options, - struct cifs_fid *fid, __u32 *oplock, FILE_ALL_INFO *buf, - struct cifs_sb_info *cifs_sb) + int disposition, int desired_access, int share_access, + int create_options, struct cifs_fid *fid, __u32 *oplock, + FILE_ALL_INFO *buf, struct cifs_sb_info *cifs_sb) { int rc; __le16 *smb2_path; @@ -87,8 +87,8 @@ smb2_open_file(const unsigned int xid, struct cifs_tcon *tcon, const char *path, memcpy(smb2_oplock + 1, fid->lease_key, SMB2_LEASE_KEY_SIZE); rc = SMB2_open(xid, tcon, smb2_path, &fid->persistent_fid, - &fid->volatile_fid, desired_access, disposition, - 0, 0, smb2_oplock, smb2_data); + &fid->volatile_fid, desired_access, share_access, + disposition, 0, 0, smb2_oplock, smb2_data); if (rc) goto out; diff --git a/fs/cifs/smb2inode.c b/fs/cifs/smb2inode.c index 7064824..6af174a 100644 --- a/fs/cifs/smb2inode.c +++ b/fs/cifs/smb2inode.c @@ -54,8 +54,8 @@ smb2_open_op_close(const unsigned int xid, struct cifs_tcon *tcon, return -ENOMEM; rc = SMB2_open(xid, tcon, utf16_path, &persistent_fid, &volatile_fid, - desired_access, create_disposition, file_attributes, - create_options, &oplock, NULL); + desired_access, FILE_SHARE_ALL, create_disposition, + file_attributes, create_options, &oplock, NULL); if (rc) { kfree(utf16_path); return rc; diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index bceffe7..22aef1d 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -222,7 +222,8 @@ smb2_is_path_accessible(const unsigned int xid, struct cifs_tcon *tcon, return -ENOMEM; rc = SMB2_open(xid, tcon, utf16_path, &persistent_fid, &volatile_fid, - FILE_READ_ATTRIBUTES, FILE_OPEN, 0, 0, &oplock, NULL); + FILE_READ_ATTRIBUTES, FILE_SHARE_ALL, FILE_OPEN, 0, 0, + &oplock, NULL); if (rc) { kfree(utf16_path); return rc; @@ -432,8 +433,8 @@ smb2_query_dir_first(const unsigned int xid, struct cifs_tcon *tcon, return -ENOMEM; rc = SMB2_open(xid, tcon, utf16_path, &persistent_fid, &volatile_fid, - FILE_READ_ATTRIBUTES | FILE_READ_DATA, FILE_OPEN, 0, 0, - &oplock, NULL); + FILE_READ_ATTRIBUTES | FILE_READ_DATA, FILE_SHARE_ALL, + FILE_OPEN, 0, 0, &oplock, NULL); kfree(utf16_path); if (rc) { cERROR(1, "open dir failed"); @@ -515,7 +516,8 @@ smb2_queryfs(const unsigned int xid, struct cifs_tcon *tcon, u8 oplock = SMB2_OPLOCK_LEVEL_NONE; rc = SMB2_open(xid, tcon, &srch_path, &persistent_fid, &volatile_fid, - FILE_READ_ATTRIBUTES, FILE_OPEN, 0, 0, &oplock, NULL); + FILE_READ_ATTRIBUTES, FILE_SHARE_ALL, FILE_OPEN, 0, 0, + &oplock, NULL); if (rc) return rc; buf->f_type = SMB2_MAGIC_NUMBER; diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 41d9d07..45fa2dc 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -910,8 +910,8 @@ parse_lease_state(struct smb2_create_rsp *rsp) int SMB2_open(const unsigned int xid, struct cifs_tcon *tcon, __le16 *path, u64 *persistent_fid, u64 *volatile_fid, __u32 desired_access, - __u32 create_disposition, __u32 file_attributes, __u32 create_options, - __u8 *oplock, struct smb2_file_all_info *buf) + __u32 share_access, __u32 create_disposition, __u32 file_attributes, + __u32 create_options, __u8 *oplock, struct smb2_file_all_info *buf) { struct smb2_create_req *req; struct smb2_create_rsp *rsp; @@ -940,7 +940,7 @@ SMB2_open(const unsigned int xid, struct cifs_tcon *tcon, __le16 *path, req->DesiredAccess = cpu_to_le32(desired_access); /* File attributes ignored on open (used in create though) */ req->FileAttributes = cpu_to_le32(file_attributes); - req->ShareAccess = FILE_SHARE_ALL_LE; + req->ShareAccess = cpu_to_le32(share_access); req->CreateDisposition = cpu_to_le32(create_disposition); req->CreateOptions = cpu_to_le32(create_options); uni_path_len = (2 * UniStrnlen((wchar_t *)path, PATH_MAX)) + 2; diff --git a/fs/cifs/smb2proto.h b/fs/cifs/smb2proto.h index 2aa3535..edff8f6 100644 --- a/fs/cifs/smb2proto.h +++ b/fs/cifs/smb2proto.h @@ -86,9 +86,10 @@ extern int smb2_create_hardlink(const unsigned int xid, struct cifs_tcon *tcon, extern int smb2_open_file(const unsigned int xid, struct cifs_tcon *tcon, const char *full_path, int disposition, - int desired_access, int create_options, - struct cifs_fid *fid, __u32 *oplock, - FILE_ALL_INFO *buf, struct cifs_sb_info *cifs_sb); + int desired_access, int share_access, + int create_options, struct cifs_fid *fid, + __u32 *oplock, FILE_ALL_INFO *buf, + struct cifs_sb_info *cifs_sb); extern void smb2_set_oplock_level(struct cifsInodeInfo *cinode, __u32 oplock); extern int smb2_unlock_range(struct cifsFileInfo *cfile, struct file_lock *flock, const unsigned int xid); @@ -108,9 +109,10 @@ extern int SMB2_tcon(const unsigned int xid, struct cifs_ses *ses, extern int SMB2_tdis(const unsigned int xid, struct cifs_tcon *tcon); extern int SMB2_open(const unsigned int xid, struct cifs_tcon *tcon, __le16 *path, u64 *persistent_fid, u64 *volatile_fid, - __u32 desired_access, __u32 create_disposition, - __u32 file_attributes, __u32 create_options, - __u8 *oplock, struct smb2_file_all_info *buf); + __u32 desired_access, __u32 share_access, + __u32 create_disposition, __u32 file_attributes, + __u32 create_options, __u8 *oplock, + struct smb2_file_all_info *buf); extern int SMB2_close(const unsigned int xid, struct cifs_tcon *tcon, u64 persistent_file_id, u64 volatile_file_id); extern int SMB2_flush(const unsigned int xid, struct cifs_tcon *tcon, -- 1.8.1.5

July 1, 2013

[PATCH v7 2/7] VFS: Add O_DENYDELETE support for VFS

by Pavel Shilovsky

Introduce new LOCK_DELETE flock flag that is suggested to be used internally only to map O_DENYDELETE open flag: !O_DENYDELETE -> LOCK_DELETE | LOCK_MAND. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/locks.c | 55 +++++++++++++++++++++++++++++++++------- fs/namei.c | 3 +++ include/linux/fs.h | 6 +++++ include/uapi/asm-generic/fcntl.h | 1 + 4 files changed, 56 insertions(+), 9 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index dbc5557..c2fa136 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -269,7 +269,7 @@ EXPORT_SYMBOL(locks_copy_lock); static inline int flock_translate_cmd(int cmd) { if (cmd & LOCK_MAND) - return cmd & (LOCK_MAND | LOCK_RW); + return cmd & (LOCK_MAND | LOCK_RW | LOCK_DELETE); switch (cmd) { case LOCK_SH: return F_RDLCK; @@ -614,6 +614,8 @@ deny_flags_to_cmd(unsigned int flags) cmd |= LOCK_READ; if (!(flags & O_DENYWRITE)) cmd |= LOCK_WRITE; + if (!(flags & O_DENYDELETE)) + cmd |= LOCK_DELETE; return cmd; } @@ -836,6 +838,33 @@ out: return error; } +int +sharelock_may_delete(struct dentry *dentry) +{ + struct file_lock **before; + int rc = 0; + + if (!IS_SHARELOCK(dentry->d_inode)) + return rc; + + lock_flocks(); + for_each_lock(dentry->d_inode, before) { + struct file_lock *fl = *before; + if (IS_POSIX(fl)) + break; + if (IS_LEASE(fl)) + continue; + if (!(fl->fl_type & LOCK_MAND)) + continue; + if (fl->fl_type & LOCK_DELETE) + continue; + rc = 1; + break; + } + unlock_flocks(); + return rc; +} + /* * Determine if a file is allowed to be opened with specified access and share * modes. Lock the file and return 0 if checks passed, otherwise return @@ -850,10 +879,6 @@ sharelock_lock_file(struct file *filp) if (!IS_SHARELOCK(filp->f_path.dentry->d_inode)) return error; - /* Disable O_DENYDELETE support for now */ - if (filp->f_flags & O_DENYDELETE) - return -EINVAL; - error = flock_make_lock(filp, &lock, deny_flags_to_cmd(filp->f_flags)); if (error) return error; @@ -1717,6 +1742,12 @@ SYSCALL_DEFINE2(flock, unsigned int, fd, unsigned int, cmd) if (!f.file) goto out; + /* LOCK_DELETE is defined to be translated from O_DENYDELETE only */ + if (cmd & LOCK_DELETE) { + error = -EINVAL; + goto out; + } + can_sleep = !(cmd & LOCK_NB); cmd &= ~LOCK_NB; unlock = (cmd == LOCK_UN); @@ -2261,10 +2292,16 @@ static void lock_get_status(struct seq_file *f, struct file_lock *fl, seq_printf(f, "UNKNOWN UNKNOWN "); } if (fl->fl_type & LOCK_MAND) { - seq_printf(f, "%s ", - (fl->fl_type & LOCK_READ) - ? (fl->fl_type & LOCK_WRITE) ? "RW " : "READ " - : (fl->fl_type & LOCK_WRITE) ? "WRITE" : "NONE "); + if (fl->fl_type & LOCK_DELETE) + seq_printf(f, "%s ", + (fl->fl_type & LOCK_READ) ? + (fl->fl_type & LOCK_WRITE) ? "RWDEL" : "RDDEL" : + (fl->fl_type & LOCK_WRITE) ? "WRDEL" : "DEL "); + else + seq_printf(f, "%s ", + (fl->fl_type & LOCK_READ) ? + (fl->fl_type & LOCK_WRITE) ? "RW " : "READ " : + (fl->fl_type & LOCK_WRITE) ? "WRITE" : "NONE "); } else { seq_printf(f, "%s ", (lease_breaking(fl)) diff --git a/fs/namei.c b/fs/namei.c index 7f6edb9..8aaffd4 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2220,6 +2220,7 @@ static inline int check_sticky(struct inode *dir, struct inode *inode) * 9. We can't remove a root or mountpoint. * 10. We don't allow removal of NFS sillyrenamed files; it's handled by * nfs_async_unlink(). + * 11. We can't do it if victim is locked by O_DENYDELETE sharelock. */ static int may_delete(struct inode *dir,struct dentry *victim,int isdir) { @@ -2250,6 +2251,8 @@ static int may_delete(struct inode *dir,struct dentry *victim,int isdir) return -ENOENT; if (victim->d_flags & DCACHE_NFSFS_RENAMED) return -EBUSY; + if (sharelock_may_delete(victim)) + return -ESHAREDENIED; return 0; } diff --git a/include/linux/fs.h b/include/linux/fs.h index 774be38..3247fb4 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1006,6 +1006,7 @@ extern int lock_may_read(struct inode *, loff_t start, unsigned long count); extern int lock_may_write(struct inode *, loff_t start, unsigned long count); extern void locks_delete_block(struct file_lock *waiter); extern int sharelock_lock_file(struct file *); +extern int sharelock_may_delete(struct dentry *); extern void lock_flocks(void); extern void unlock_flocks(void); #else /* !CONFIG_FILE_LOCKING */ @@ -1159,6 +1160,11 @@ static inline int sharelock_lock_file(struct file *filp) return 0; } +static inline int sharelock_may_delete(struct dentry *dentry) +{ + return 0; +} + static inline void lock_flocks(void) { } diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h index 5ac0d49..a3e6349 100644 --- a/include/uapi/asm-generic/fcntl.h +++ b/include/uapi/asm-generic/fcntl.h @@ -167,6 +167,7 @@ struct f_owner_ex { blocking */ #define LOCK_UN 8 /* remove lock */ +#define LOCK_DELETE 16 /* which allows to delete a file */ #define LOCK_MAND 32 /* This is a mandatory flock ... */ #define LOCK_READ 64 /* which allows concurrent read operations */ #define LOCK_WRITE 128 /* which allows concurrent write operations */ -- 1.8.1.5

July 1, 2013

[PATCH v7 1/7] VFS: Introduce new O_DENY* open flags

by Pavel Shilovsky

This patch adds 3 flags: 1) O_DENYREAD that doesn't permit read access, 2) O_DENYWRITE that doesn't permit write access, 3) O_DENYDELETE that doesn't permit delete or rename. Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules as well as Samba and NFS file servers that export the same directory for Windows clients, or Wine applications that access the same files simultaneously. These flags are only take affect for opens on mounts with new sharelock option. They are translated to flock's flags: !O_DENYREAD -> LOCK_READ | LOCK_MAND !O_DENYWRITE -> LOCK_WRITE | LOCK_MAND and set through flock_lock_file on a file. If the file can't be locked due conflicts with another open with O_DENY* flags, a new -ESHAREDENIED error code is returned. Create codepath is slightly changed to prevent data races on newly created files: when open with O_CREAT can return -ESHAREDENIED error for successfully created files due to a sharelock set by another task. Temporary disable O_DENYDELETE support - will enable it in further patches. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- arch/alpha/include/uapi/asm/errno.h | 2 + arch/mips/include/uapi/asm/errno.h | 2 + arch/parisc/include/uapi/asm/errno.h | 2 + arch/sparc/include/uapi/asm/errno.h | 2 + fs/fcntl.c | 5 +- fs/locks.c | 97 +++++++++++++++++++++++++++++++++--- fs/namei.c | 53 +++++++++++++++++++- fs/proc_namespace.c | 1 + include/linux/fs.h | 7 +++ include/uapi/asm-generic/errno.h | 2 + include/uapi/asm-generic/fcntl.h | 11 ++++ include/uapi/linux/fs.h | 1 + 12 files changed, 175 insertions(+), 10 deletions(-) diff --git a/arch/alpha/include/uapi/asm/errno.h b/arch/alpha/include/uapi/asm/errno.h index e5f29ca..f51b81b 100644 --- a/arch/alpha/include/uapi/asm/errno.h +++ b/arch/alpha/include/uapi/asm/errno.h @@ -124,4 +124,6 @@ #define EHWPOISON 139 /* Memory page has hardware error */ +#define ESHAREDENIED 140 /* File is locked with a sharelock */ + #endif diff --git a/arch/mips/include/uapi/asm/errno.h b/arch/mips/include/uapi/asm/errno.h index 31575e2f..dda1c73 100644 --- a/arch/mips/include/uapi/asm/errno.h +++ b/arch/mips/include/uapi/asm/errno.h @@ -123,6 +123,8 @@ #define EHWPOISON 168 /* Memory page has hardware error */ +#define ESHAREDENIED 169 /* File is locked with a sharelock */ + #define EDQUOT 1133 /* Quota exceeded */ diff --git a/arch/parisc/include/uapi/asm/errno.h b/arch/parisc/include/uapi/asm/errno.h index 135ad60..bda01d5 100644 --- a/arch/parisc/include/uapi/asm/errno.h +++ b/arch/parisc/include/uapi/asm/errno.h @@ -124,4 +124,6 @@ #define EHWPOISON 257 /* Memory page has hardware error */ +#define ESHAREDENIED 258 /* File is locked with a sharelock */ + #endif diff --git a/arch/sparc/include/uapi/asm/errno.h b/arch/sparc/include/uapi/asm/errno.h index c351aba..836eded 100644 --- a/arch/sparc/include/uapi/asm/errno.h +++ b/arch/sparc/include/uapi/asm/errno.h @@ -114,4 +114,6 @@ #define EHWPOISON 135 /* Memory page has hardware error */ +#define ESHAREDENIED 136 /* File is locked with a sharelock */ + #endif diff --git a/fs/fcntl.c b/fs/fcntl.c index 6599222..a1eee47 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -730,14 +730,15 @@ static int __init fcntl_init(void) * Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY * is defined as O_NONBLOCK on some platforms and not on others. */ - BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32( + BUILD_BUG_ON(22 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32( O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | O_APPEND | /* O_NONBLOCK | */ __O_SYNC | O_DSYNC | FASYNC | O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | O_NOATIME | O_CLOEXEC | - __FMODE_EXEC | O_PATH + __FMODE_EXEC | O_PATH | O_DENYREAD | + O_DENYWRITE | O_DENYDELETE )); fasync_cache = kmem_cache_create("fasync_cache", diff --git a/fs/locks.c b/fs/locks.c index cb424a4..dbc5557 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -605,20 +605,73 @@ static int posix_locks_conflict(struct file_lock *caller_fl, struct file_lock *s return (locks_conflict(caller_fl, sys_fl)); } -/* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific - * checking before calling the locks_conflict(). +static unsigned int +deny_flags_to_cmd(unsigned int flags) +{ + unsigned int cmd = LOCK_MAND; + + if (!(flags & O_DENYREAD)) + cmd |= LOCK_READ; + if (!(flags & O_DENYWRITE)) + cmd |= LOCK_WRITE; + + return cmd; +} + +/* + * locks_mand_conflict - Determine if there's a share reservation conflict + * @caller_fl: lock we're attempting to acquire + * @sys_fl: lock already present on system that we're checking against + * + * 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) +{ + unsigned char caller_type = caller_fl->fl_type; + unsigned char sys_type = sys_fl->fl_type; + fmode_t caller_fmode = caller_fl->fl_file->f_mode; + fmode_t sys_fmode = sys_fl->fl_file->f_mode; + + /* they can only conflict if FS is mounted with MS_SHARELOCK */ + if (!IS_SHARELOCK(caller_fl->fl_file->f_path.dentry->d_inode)) + return 0; + + /* they can only conflict if they're both LOCK_MAND */ + if (!(caller_type & LOCK_MAND) || !(sys_type & LOCK_MAND)) + return 0; + + if (!(caller_type & LOCK_READ) && (sys_fmode & FMODE_READ)) + return 1; + if (!(caller_type & LOCK_WRITE) && (sys_fmode & FMODE_WRITE)) + return 1; + if (!(sys_type & LOCK_READ) && (caller_fmode & FMODE_READ)) + return 1; + if (!(sys_type & LOCK_WRITE) && (caller_fmode & FMODE_WRITE)) + return 1; + + return 0; +} + +/* + * Determine if lock sys_fl blocks lock caller_fl. FLOCK specific checking + * before calling the locks_conflict(). */ static int flock_locks_conflict(struct file_lock *caller_fl, struct file_lock *sys_fl) { - /* FLOCK locks referring to the same filp do not conflict with + if (!IS_FLOCK(sys_fl)) + return 0; + if ((caller_fl->fl_type & LOCK_MAND) || (sys_fl->fl_type & LOCK_MAND)) + return locks_mand_conflict(caller_fl, sys_fl); + /* + * FLOCK locks referring to the same filp do not conflict with * each other. */ - if (!IS_FLOCK(sys_fl) || (caller_fl->fl_file == sys_fl->fl_file)) - return (0); - if ((caller_fl->fl_type & LOCK_MAND) || (sys_fl->fl_type & LOCK_MAND)) + if (caller_fl->fl_file == sys_fl->fl_file) return 0; - return (locks_conflict(caller_fl, sys_fl)); + return locks_conflict(caller_fl, sys_fl); } void @@ -783,6 +836,36 @@ out: return error; } +/* + * Determine if a file is allowed to be opened with specified access and share + * modes. Lock the file and return 0 if checks passed, otherwise return + * -ESHAREDENIED. + */ +int +sharelock_lock_file(struct file *filp) +{ + struct file_lock *lock; + int error = 0; + + if (!IS_SHARELOCK(filp->f_path.dentry->d_inode)) + return error; + + /* Disable O_DENYDELETE support for now */ + if (filp->f_flags & O_DENYDELETE) + return -EINVAL; + + error = flock_make_lock(filp, &lock, deny_flags_to_cmd(filp->f_flags)); + if (error) + return error; + + error = flock_lock_file(filp, lock); + if (error == -EAGAIN) + error = -ESHAREDENIED; + + locks_free_lock(lock); + return error; +} + static int __posix_lock_file(struct inode *inode, struct file_lock *request, struct file_lock *conflock) { struct file_lock *fl; diff --git a/fs/namei.c b/fs/namei.c index 85e40d1..7f6edb9 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2548,9 +2548,14 @@ static int atomic_open(struct nameidata *nd, struct dentry *dentry, * here. */ error = may_open(&file->f_path, acc_mode, open_flag); - if (error) + if (error) { fput(file); + goto out; + } + error = sharelock_lock_file(file); + if (error) + fput(file); out: dput(dentry); return error; @@ -2760,6 +2765,40 @@ retry_lookup: } mutex_lock(&dir->d_inode->i_mutex); error = lookup_open(nd, path, file, op, got_write, opened); + + /* + * 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); if (error <= 0) { @@ -2874,6 +2913,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: error = open_check_o_direct(file); if (error) diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c index 2033f74..6edbadc 100644 --- a/fs/proc_namespace.c +++ b/fs/proc_namespace.c @@ -44,6 +44,7 @@ static int show_sb_opts(struct seq_file *m, struct super_block *sb) { MS_SYNCHRONOUS, ",sync" }, { MS_DIRSYNC, ",dirsync" }, { MS_MANDLOCK, ",mand" }, + { MS_SHARELOCK, ",sharelock" }, { 0, NULL } }; const struct proc_fs_info *fs_infop; diff --git a/include/linux/fs.h b/include/linux/fs.h index 5c49108..774be38 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1005,6 +1005,7 @@ extern int lease_modify(struct file_lock **, int); extern int lock_may_read(struct inode *, loff_t start, unsigned long count); extern int lock_may_write(struct inode *, loff_t start, unsigned long count); extern void locks_delete_block(struct file_lock *waiter); +extern int sharelock_lock_file(struct file *); extern void lock_flocks(void); extern void unlock_flocks(void); #else /* !CONFIG_FILE_LOCKING */ @@ -1153,6 +1154,11 @@ static inline void locks_delete_block(struct file_lock *waiter) { } +static inline int sharelock_lock_file(struct file *filp) +{ + return 0; +} + static inline void lock_flocks(void) { } @@ -1668,6 +1674,7 @@ struct super_operations { #define IS_PRIVATE(inode) ((inode)->i_flags & S_PRIVATE) #define IS_IMA(inode) ((inode)->i_flags & S_IMA) #define IS_AUTOMOUNT(inode) ((inode)->i_flags & S_AUTOMOUNT) +#define IS_SHARELOCK(inode) __IS_FLG(inode, MS_SHARELOCK) #define IS_NOSEC(inode) ((inode)->i_flags & S_NOSEC) /* diff --git a/include/uapi/asm-generic/errno.h b/include/uapi/asm-generic/errno.h index a1331ce..19ab5f4 100644 --- a/include/uapi/asm-generic/errno.h +++ b/include/uapi/asm-generic/errno.h @@ -110,4 +110,6 @@ #define EHWPOISON 133 /* Memory page has hardware error */ +#define ESHAREDENIED 134 /* File is locked with a sharelock */ + #endif diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h index a48937d..5ac0d49 100644 --- a/include/uapi/asm-generic/fcntl.h +++ b/include/uapi/asm-generic/fcntl.h @@ -84,6 +84,17 @@ #define O_PATH 010000000 #endif +#ifndef O_DENYREAD +#define O_DENYREAD 020000000 /* Do not permit read access */ +#endif +#ifndef O_DENYWRITE +#define O_DENYWRITE 040000000 /* Do not permit write access */ +#endif +/* FMODE_NONOTIFY 0100000000 */ +#ifndef O_DENYDELETE +#define O_DENYDELETE 0200000000 /* Do not permit delete or rename */ +#endif + #ifndef O_NDELAY #define O_NDELAY O_NONBLOCK #endif diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h index c7fc1e6..2af7269 100644 --- a/include/uapi/linux/fs.h +++ b/include/uapi/linux/fs.h @@ -86,6 +86,7 @@ struct inodes_stat_t { #define MS_KERNMOUNT (1<<22) /* this is a kern_mount call */ #define MS_I_VERSION (1<<23) /* Update inode I_version field */ #define MS_STRICTATIME (1<<24) /* Always perform atime updates */ +#define MS_SHARELOCK (1<<25) /* Allow share locks on an FS */ /* These sb flags are internal to the kernel */ #define MS_SNAP_STABLE (1<<27) /* Snapshot pages during writeback, if needed */ -- 1.8.1.5

July 1, 2013

[PATCH v7 0/7] Add O_DENY* support for VFS and CIFS/NFS

by Pavel Shilovsky

Main changes from v6: 1) Fix LOCK_DELETE mandatory lock detection for O_DENYDELETE opens. 2) Add ESHAREDENIED error code definition for alpha, mips, parisc and sparc arches. 3) Remove code changes in do_last function if sharelocks are disabled. Main changes from v5: 1) O_DENYDELETE is now supported by VFS. 2) ESHAREDENIED erro code is introduced to be returned on sharelock conflicts. 3) forcemand dependancy is removed. CIFS module detects if it should use NTCreateAndX command according to existence of O_DENY flags. 4) Term 'deny lock' is replaced by 'sharelock' (function names, code comments, patch descriptions). Main changes from v4: 1) deny_lock_file uses FS_DOES_SHARELOCK flag from fs_flags to determine whether to use VFS locks or not. 2) Make nfs code return -EBUSY for share conflicts (was -EACCESS). Main changes from v3 1) O_DENYMAND is removed, sharelock mount option is introduced. 2) Patch fcntl.h and VFS patches are united into one. 3) flock/LOCK_MAND is disabled for sharelock mounts. This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanism, but that approach is non-atomic. This patchset builds new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why extra mount option 'sharelock' is added for switching on/off O_DENY* flags processing. It allows us to avoid use of these flags on critical places (like /, /lib) and turn them on if we really want it proccessed that way. The patchset introduces 3 new flags: O_DENYREAD - to prevent other opens with read access, O_DENYWRITE - to prevent other opens with write access, O_DENYDELETE - to prevent delete operations (this flag can't be implemented for NFS due to the protocol restrictions). The patchset avoids data races problem on newely created files: open with O_CREAT can return new -ESHAREDENIED error code for a successfully created file if this files was locked with a sharelock by another task. Also, it turns off flock/LOCK_MAND capability for mounts with 'sharelock' option. This lets us not mix one share reservation approach with another. The #1 and #2 patches add flags to fcntl and implements VFS part. The patches #3 and #4 are related to CIFS-specific changes, #5 and #6 describe NFS and NFSD parts, #7 turns off flock/LOCK_MAND for mounts with 'sharelock' option. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- O_DENYREAD, O_DENYWRIYE, O_DENYDELETE - used to inforce a mandatory share reservation scheme of the file access. If these flag is passed, the open fails with -ESHAREDENIED in following cases: 1) if O_DENYREAD flag is specified and there is another open with READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYWRITE flags. If O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ESHAREDENIED untill this open is closed. Now this flag is processed by VFS and CIFS filesystem. This mechanism is done through flocks. If O_DENY* flags are specified, flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) !O_DENYREAD -> LOCK_READ | LOCK_MAND 2) !O_DENYWRITE -> LOCK_WRITE | LOCK_MAND 3) !O_DENYDELETE -> LOCK_DELETE | LOCK_MAND --- Pavel Shilovsky (7): VFS: Introduce new O_DENY* open flags VFS: Add O_DENYDELETE support for VFS CIFS: Add share_access parm to open request CIFS: Add O_DENY* open flags support NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS locks: Disable LOCK_MAND support for MS_SHARELOCK mounts arch/alpha/include/uapi/asm/errno.h | 2 + arch/mips/include/uapi/asm/errno.h | 2 + arch/parisc/include/uapi/asm/errno.h | 2 + arch/sparc/include/uapi/asm/errno.h | 2 + fs/cifs/cifsacl.c | 8 +- fs/cifs/cifsfs.c | 2 +- fs/cifs/cifsglob.h | 18 +++- fs/cifs/cifsproto.h | 8 +- fs/cifs/cifssmb.c | 50 ++++++----- fs/cifs/dir.c | 16 ++-- fs/cifs/file.c | 25 ++++-- fs/cifs/inode.c | 21 ++--- fs/cifs/link.c | 25 ++---- fs/cifs/netmisc.c | 2 +- fs/cifs/readdir.c | 5 +- fs/cifs/smb1ops.c | 16 ++-- fs/cifs/smb2file.c | 10 +-- fs/cifs/smb2inode.c | 4 +- fs/cifs/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +-- fs/fcntl.c | 5 +- fs/locks.c | 160 ++++++++++++++++++++++++++++++++--- fs/namei.c | 56 +++++++++++- fs/nfs/dir.c | 4 + fs/nfs/internal.h | 3 +- fs/nfs/nfs4file.c | 4 + fs/nfs/nfs4proc.c | 4 +- fs/nfs/nfs4super.c | 9 +- fs/nfs/nfs4xdr.c | 21 ++++- fs/nfs/super.c | 6 +- fs/nfsd/nfs4state.c | 46 +++++++++- fs/nfsd/nfsproc.c | 1 + fs/proc_namespace.c | 1 + include/linux/fs.h | 14 +++ include/uapi/asm-generic/errno.h | 2 + include/uapi/asm-generic/fcntl.h | 12 +++ include/uapi/linux/fs.h | 1 + 39 files changed, 464 insertions(+), 135 deletions(-) -- 1.8.1.5

July 1, 2013

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-07-01 18:13+0200 Peter Rosin wrote: > On 2013-06-29 18:33, Alan W. Irwin wrote: >> Those have been mentioned before here, and I have looked at them. >> Cygwin is a very large collection of software so the number of bugs >> that are reported does not seem excessive to me, and for my personal >> needs (building and testing software on the Cygwin platform) I will >> only be using a subset of Cygwin so I may avoid encountering >> some of these bugs. Furthermore, some of these bugs (e.g., >> problems resizing a GUI) are not showstoppers, and most of them are >> quite old. At the same time the latest Wine is far superior to >> Wine-1.4 so some of those bugs may have just disappeared. I hope to >> find out about the actual status of Cygwin on Wine >> bugs once I can get setup.exe to work on Wine. > > I would like to point out that it seems that the current bug does not > appear to be *in* setup.exe, but rather occurs when setup.exe runs > a bash post-install script, where the bash.exe that interprets the > script depends on cygwin1.dll. If my analysis is correct, the bug > would occur also when duplicating the actions of setup.exe manually. > You would have to also duplicate the actions of all post-install > scripts, which is certainly more work and more error-prone than > duplicating the download and unpacking of a few tarballs. Hi Peter: That analysis is absolutely correct, and the current hang I am getting for that post-install script (/etc/postinstall/000-cygwin-post-install.sh) is a puzzler since that occurs with or without the fork-fixed cygwin1.dll and the hang is new behaviour compared to the result I got a month ago (obviously without the fork-fixed cygwin1.dll) where I got an abort with an explicit error message in agreement with the 24018 bug report. So I hope others here with some cygwin experience will investigate further since I might be doing something inadvertently different than before when I replicated the behaviour reported in the 24018 bug report exactly. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

July 1, 2013

Re: [wine-devel] Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-07-01 06:13+0100 Hin-Tak Leung wrote: > [...]In terms of "relative" importance, consider that mingw (both native and cross) GNU toolchain works well, > the toolchain part of cygwin is hardly a priority. Once again you are implying the MinGW GNU toolchain is better than the Cygwin GNU toolchain without mention of any bug reports from you to Cygwin to back up that assertion. Your constant repetition of this theme made me curious so I looked you up on the web, and it appears you are a MinGW developer. If you really are a MinGW developer, I hope your negative attitude toward the Cygwin toolchain is not typical of such developers. After all, even though the Windows GNU toolchain code bases have diverged between the two groups of developers, there is still a common interest between MinGW and Cygwin developers regarding getting the GNU toolchain to work properly on Windows. You certainly have the right to express your opinion about the Cygwin toolchain here, and you _might_ even be correct, but I am concerned you are biased since you appear to be broadcasting anecdotal evidence without sending in bug reports to Cygwin concerning what you have found. And now to get back on topic again, thanks, André, for that reference to http://wiki.winehq.org/CygwinSupport. The two points there are worth repeating: For Wine, the upside would be: * a very good test suite * a much more solid implementation of the fundamental Win32 APIs These same points can be made about MinGW/MSYS and my work on building software (whose build is configured by my "build_projects" project) on Wine with that toolchain. And that work has already contributed to 3 Wine fixes (two of which were regressions introduced in the 1.5.x series). However, it should be emphasized that Cygwin is a very much bigger free software project than MinGW/MSYS. So it provides a much more comprehensive and rigourous test of Wine than MinGW/MSYS, and this will be the case for the forseeable future. The number of software projects whose builds are configured by build_projects is growing, but that number it is still very much smaller than the list of software builds that are included in the Cygwin distribution. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

July 1, 2013

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Peter Rosin

On 2013-06-29 18:33, Alan W. Irwin wrote: > Those have been mentioned before here, and I have looked at them. > Cygwin is a very large collection of software so the number of bugs > that are reported does not seem excessive to me, and for my personal > needs (building and testing software on the Cygwin platform) I will > only be using a subset of Cygwin so I may avoid encountering > some of these bugs. Furthermore, some of these bugs (e.g., > problems resizing a GUI) are not showstoppers, and most of them are > quite old. At the same time the latest Wine is far superior to > Wine-1.4 so some of those bugs may have just disappeared. I hope to > find out about the actual status of Cygwin on Wine > bugs once I can get setup.exe to work on Wine. I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually. You would have to also duplicate the actions of all post-install scripts, which is certainly more work and more error-prone than duplicating the download and unpacking of a few tarballs. Cheers, Peter

July 1, 2013

Possible help or direction to build Win to Linux pass through device - resent

by Pavel Pisa

Hello all Wine developers, [the second attempt to send, is the list subscribers only?] the firs I would like to express my respect to the work done. Now to one of our application, we maintain open-source chromatographic software CHROMuLAN https://sourceforge.net/projects/chromulan/ Unfortunately, it is written in Delphi (version 6 used) and we have not resources to port it to run native on Linux even that Linux is for last 18 years our main development platform for embedded hardware design and development. Our long term is to port application to Lazarus/FPC or even rewrite in in Qt but that is not option now. Fortunately, the CHROMuLAN application runs quite well under latest Wine version. But we have problem with access to the data acquisition hardware. The devices are connected to computer through special protocol (uLAN) RS-485 network. We have drivers for Linux (the firs platform), Windows (even 64-bit tested) and other targets. All for PCI, RS-232/485 converters and PCI RS-485 addon cards. Whole stack even runs under ReactOS in QEMU now. But Wine is more pleasant solution when someone uses Linux as his/her main desktop system. https://sourceforge.net/projects/ulan/ Problem is that I loke to provide driver API to the Wine application. The real windows driver is KMD/WMD "ul_wdm.sys" which is registered as "\\\\.\\UL_DRV" by IoCreateDevice and IoCreateSymbolicLink. Driver provides some context per each open and then read, write and iocts are used. We have exactly the same drive for Linux (x86, 64-bit, MIPS, ARM, PowerPC) with same functionality but Linux IOCTLs numbers are built different way and there are some slight differences caused by differences in Win API IOCTLs processing and Windows does not support poll equivalent for devices too. I have studied Wine and wineserver more times and have not found how to achieve provision of the Linux driver to the Wine application. Or more or less found that there would be problem because wineserver seems to deliver only IOCTLs events. But I was not sure so I have finally proven that by trial. I have written DLL/SYS as a driver supporting all required IRP_MJ_xxx and IOCTLs in the style of KMD/WMD driver and implemented functions as calling to the Linux "/dev/ulan" operation equivalents. But it really does not work. Only IOCTLs are delivered to the ul_drv.sys and even that fails because open context is not setup. Pointer irpStack->FileObject is filled with 0x66666666. You can find my attempt at http://cmp.felk.cvut.cz/~pisa/ulan/wine/ Now to the questions, Is there some mechanism in Wine which I could use? Is there chance to do that as little intrusive (i.e. DLL) that it can be acceptable for Wine mainline? It seems that serial port device somehow solves similar problem but is seems to be hardwired to wineserv. As for my case, it is possible that read and write to the open /dev/ulan file are done directly from context of application if it receives Linux filehandle into wine/dlls/ntdll/file.c . If the new FD_TYPE_ (FD_TYPE_SERIAL) is defined then all processing can be done in Linux native NTDLL. Even IOCTLs translation because they are really straightforward (like wine-git/dlls/ntdll/serial.c does in COMM_DeviceIoControl). But such solution seems intrusive to me. On the other hand the structure struct object_ops in wine/wine/server/object.h seems to provide all operations. Can I use some registration in the server to solve access? I am missing something? Is there some suggestion which approach to take? Some reasonable simple solution is preferred because if projects takes too much time it would even more postpone possibility to start real application porting. Thanks for each possible advice, Pavel -- Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

July 1, 2013

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

by Rosen Diankov

you are right, i'm attaching a new patch. 2013/7/1 Hans Leidekker <hans(a)codeweavers.com>: > On Mon, 2013-07-01 at 08:56 +0900, Rosen Diankov wrote: > >> diff -ru wine-1.6-rc3-old/dlls/wbemprox/builtin.c wine-1.6-rc3/dlls/wbemprox/builtin.c >> --- wine-1.6-rc3-old/dlls/wbemprox/builtin.c 2013-06-22 03:24:01.000000000 +0900 >> +++ wine-1.6-rc3/dlls/wbemprox/builtin.c 2013-06-27 23:04:20.170154454 +0900 > > Please use git to generate patches. > >> @@ -168,6 +168,8 @@ >> {'M','a','n','u','f','a','c','t','u','r','e','r',0}; >> static const WCHAR prop_maxclockspeedW[] = >> {'M','a','x','C','l','o','c','k','S','p','e','e','d',0}; >> +static const WCHAR prop_currentclockspeedW[] = >> + {'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0}; > > Please keep properties sorted here and below. > >> static const WCHAR prop_memberW[] = >> {'M','e','m','b','e','r',0}; >> static const WCHAR prop_methodW[] = >> @@ -381,6 +383,7 @@ >> { prop_familyW, CIM_UINT16, VT_I4 }, >> { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC }, >> { prop_maxclockspeedW, CIM_UINT32, VT_I4 }, >> + { prop_currentclockspeedW, CIM_UINT32, VT_I4 }, >> { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC }, >> { prop_numcoresW, CIM_UINT32, VT_I4 }, >> { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 }, >> @@ -633,6 +636,7 @@ >> UINT16 family; >> const WCHAR *manufacturer; >> UINT32 maxclockspeed; >> + UINT32 currentclockspeed; >> const WCHAR *name; >> UINT32 num_cores; >> UINT32 num_logical_processors; >> @@ -1690,7 +1694,33 @@ >> regs_to_str( regs, 16, name + 32 ); >> } >> } >> -static UINT get_processor_maxclockspeed( void ) >> +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT* currentclockspeed ) >> +{ >> + PROCESSOR_POWER_INFORMATION *info; >> + UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); >> + NTSTATUS status; >> + >> + if ((info = heap_alloc( size ))) >> + { >> + status = NtPowerInformation( ProcessorInformation, NULL, 0, info, size ); >> + if (!status) >> + { >> + *maxclockspeed = info[0].MaxMhz; >> + *currentclockspeed = info[0].CurrentMhz; >> + } >> + heap_free( info ); >> + } >> + if( !!maxclockspeed ) >> + { >> + *maxclockspeed = 1000; >> + } >> + if( !!currentclockspeed ) >> + { >> + *currentclockspeed = 1000; >> + } >> +} > > You probably didn't mean to query the clock speeds and then overwrite them with static values. > NULL checks are not needed in helpers like this. > >> +/*static UINT get_processor_maxclockspeed( void ) >> { >> PROCESSOR_POWER_INFORMATION *info; >> UINT ret = 1000, size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); >> @@ -1703,7 +1733,8 @@ >> heap_free( info ); >> } >> return ret; >> -} >> +}*/ > > Don't comment out code. Remove it. > >> static const WCHAR *get_osarchitecture(void) >> { >> SYSTEM_INFO info; >> @@ -1717,7 +1748,7 @@ >> static const WCHAR fmtW[] = {'C','P','U','%','u',0}; >> WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0}; >> struct record_processor *rec; >> - UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors, count = get_processor_count(); >> + UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0, num_cores, num_logical_processors, count = get_processor_count(); >> enum fill_status status = FILL_STATUS_UNFILTERED; >> >> if (!resize_table( table, count, sizeof(*rec) )) return FILL_STATUS_FAILED; >> @@ -1726,7 +1757,7 @@ >> get_processor_manufacturer( manufacturer ); >> get_processor_name( name ); >> >> - maxclockspeed = get_processor_maxclockspeed(); >> + get_processor_clockspeeds(&maxclockspeed, &currentclockspeed); >> num_logical_processors = get_logical_processor_count( &num_cores ) / count; >> num_cores /= count; > > You're not using currentclockspeed. > >

July 1, 2013

Re: [wbemprox] Patches for adding currentclockspeed in record_processor

by Hans Leidekker

On Mon, 2013-07-01 at 08:56 +0900, Rosen Diankov wrote: > diff -ru wine-1.6-rc3-old/dlls/wbemprox/builtin.c wine-1.6-rc3/dlls/wbemprox/builtin.c > --- wine-1.6-rc3-old/dlls/wbemprox/builtin.c 2013-06-22 03:24:01.000000000 +0900 > +++ wine-1.6-rc3/dlls/wbemprox/builtin.c 2013-06-27 23:04:20.170154454 +0900 Please use git to generate patches. > @@ -168,6 +168,8 @@ > {'M','a','n','u','f','a','c','t','u','r','e','r',0}; > static const WCHAR prop_maxclockspeedW[] = > {'M','a','x','C','l','o','c','k','S','p','e','e','d',0}; > +static const WCHAR prop_currentclockspeedW[] = > + {'C','u','r','r','e','n','t','C','l','o','c','k','S','p','e','e','d',0}; Please keep properties sorted here and below. > static const WCHAR prop_memberW[] = > {'M','e','m','b','e','r',0}; > static const WCHAR prop_methodW[] = > @@ -381,6 +383,7 @@ > { prop_familyW, CIM_UINT16, VT_I4 }, > { prop_manufacturerW, CIM_STRING|COL_FLAG_DYNAMIC }, > { prop_maxclockspeedW, CIM_UINT32, VT_I4 }, > + { prop_currentclockspeedW, CIM_UINT32, VT_I4 }, > { prop_nameW, CIM_STRING|COL_FLAG_DYNAMIC }, > { prop_numcoresW, CIM_UINT32, VT_I4 }, > { prop_numlogicalprocessorsW, CIM_UINT32, VT_I4 }, > @@ -633,6 +636,7 @@ > UINT16 family; > const WCHAR *manufacturer; > UINT32 maxclockspeed; > + UINT32 currentclockspeed; > const WCHAR *name; > UINT32 num_cores; > UINT32 num_logical_processors; > @@ -1690,7 +1694,33 @@ > regs_to_str( regs, 16, name + 32 ); > } > } > -static UINT get_processor_maxclockspeed( void ) > +static void get_processor_clockspeeds( UINT* maxclockspeed, UINT* currentclockspeed ) > +{ > + PROCESSOR_POWER_INFORMATION *info; > + UINT size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); > + NTSTATUS status; > + > + if ((info = heap_alloc( size ))) > + { > + status = NtPowerInformation( ProcessorInformation, NULL, 0, info, size ); > + if (!status) > + { > + *maxclockspeed = info[0].MaxMhz; > + *currentclockspeed = info[0].CurrentMhz; > + } > + heap_free( info ); > + } > + if( !!maxclockspeed ) > + { > + *maxclockspeed = 1000; > + } > + if( !!currentclockspeed ) > + { > + *currentclockspeed = 1000; > + } > +} You probably didn't mean to query the clock speeds and then overwrite them with static values. NULL checks are not needed in helpers like this. > +/*static UINT get_processor_maxclockspeed( void ) > { > PROCESSOR_POWER_INFORMATION *info; > UINT ret = 1000, size = get_processor_count() * sizeof(PROCESSOR_POWER_INFORMATION); > @@ -1703,7 +1733,8 @@ > heap_free( info ); > } > return ret; > -} > +}*/ Don't comment out code. Remove it. > static const WCHAR *get_osarchitecture(void) > { > SYSTEM_INFO info; > @@ -1717,7 +1748,7 @@ > static const WCHAR fmtW[] = {'C','P','U','%','u',0}; > WCHAR device_id[14], processor_id[17], manufacturer[13], name[49] = {0}; > struct record_processor *rec; > - UINT i, offset = 0, maxclockspeed, num_cores, num_logical_processors, count = get_processor_count(); > + UINT i, offset = 0, maxclockspeed = 0, currentclockspeed = 0, num_cores, num_logical_processors, count = get_processor_count(); > enum fill_status status = FILL_STATUS_UNFILTERED; > > if (!resize_table( table, count, sizeof(*rec) )) return FILL_STATUS_FAILED; > @@ -1726,7 +1757,7 @@ > get_processor_manufacturer( manufacturer ); > get_processor_name( name ); > > - maxclockspeed = get_processor_maxclockspeed(); > + get_processor_clockspeeds(&maxclockspeed, &currentclockspeed); > num_logical_processors = get_logical_processor_count( &num_cores ) / count; > num_cores /= count; You're not using currentclockspeed.

July 1, 2013

Re: po: Arabic full translated wine. (try2)

by Yaron Shahrabani

Non critical changes but take a look if you like: #: comdlg32.rc:186 comdlg32.rc:141 -#, fuzzy msgid "Save As" msgstr "احفظ &ك‍..." Redundant Elipsis. #: comdlg32.rc:202 -#, fuzzy msgid "S&election" -msgstr "اختر ال&كل\tCtrl+A" +msgstr "الاختيار" #: comdlg32.rc:203 -#, fuzzy msgid "&Pages" -msgstr "صفحة &p" +msgstr "صفحات" #: comdlg32.rc:206 comdlg32.rc:228 -#, fuzzy msgid "&Setup" -msgstr "إعداد الصفحة" +msgstr "إعداد" No accelerator (&) sign. #: comdlg32.rc:207 msgid "&From:" -msgstr "" +msgstr "&من" #: comdlg32.rc:208 msgid "&To:" -msgstr "" +msgstr "&إلى" No semicolon at the end. #: comdlg32.rc:211 -#, fuzzy msgid "Print to Fi&le" -msgstr "ملفات النصوص (*.txt)" +msgstr "اطبع إلى ملف" #: comdlg32.rc:268 msgid "Scr&ipt:" -msgstr "" +msgstr "ترميز" No accelerator sign. #: comdlg32.rc:281 comdlg32.rc:304 msgid "Color | Sol&id" -msgstr "" +msgstr "اللون | &جامد" No need to add اللون |‏ before the &جامد part. There might be more. Anyways great job! Kind regards, Yaron Shahrabani <Hebrew translator> On Sun, Jun 30, 2013 at 6:27 AM, مصعب الزعبي <moceap(a)hotmail.com> wrote: > --- > > po/ar.po > > > > > >

July 1, 2013

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Hin-Tak Leung

--- On Sun, 30/6/13, André Hentschel <nerv(a)dawncrow.de> wrote: > On 29.06.2013 23:34, Hin-Tak Leung > wrote: > > --- On Sat, 29/6/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> > wrote: > > > > ... > >>> Also, running cygwin on wine, compared to other > windows > >> software > >> which has no unix/linux equivalents, is hardly a > priority. > >> > >> That is obviously personally true for you. > And for my > >> personal needs > >> Cygwin on Wine is a "would be nice" software build > and test > >> platform. > > ... > > > > No. Just the fact that nobody else bothered to respond > to this thread should convince you that getting cygwin is > not a priority to most people who is knowledgeable and > capable of hacking wine. > > > > I've been following this thread. What i would like to point > you all to is: > http://wiki.winehq.org/CygwinSupport > It describes why running cygwin on wine is not that > senseless low priority thing. > Further it's mentioned at: > http://wiki.winehq.org/TodoList and > http://wiki.winehq.org/UnitTestSuites Wiki is what it is - anybody with a wish can add an entry. If somebody put their name down and say: "*I* will do this!" - and have the knowledge & incentive to deliver, that's when it gets interesting. Until then, it is not. (Those entries might just have been added by the original poster of this thread - doesn't prove anything). Using words like "showstopper" is off-putting. Especially considering there are at least two well-known(?) ways of getting around a mere installation problem of a piece of [any] open-source software - (1) unpack manually. It is open-source and all the actions of the installer are known; (2) copy from an existing installation & clone the relevant registry entries. and (3) being able to install is not a warranty it will run. In terms of "relative" importance, consider that mingw (both native and cross) GNU toolchain works well, the toolchain part of cygwin is hardly a priority; further, between mingw and MSVC (note the distinction - I mean mingw, not cygwin), I would rather spend time improving wine's support for MSVC . That is an interesting observation - getting microsoft products to work well is obviously a priority to the wider community & to Crossover, but that isn't mentioned much in those wiki pages.

July 1, 2013

Re: po: Update Czech translation - 2nd attempt

by Nikolay Sivov

On 6/28/2013 18:21, Pavel Borecki wrote: Hi, Pavel. Looks like you're using poedit or something with similar habit of touching lines location headers: --- > -#: appwiz.rc:66 appwiz.rc:42 cryptui.rc:343 msacm32.rc:37 winecfg.rc:191 > -#: winecfg.rc:228 wordpad.rc:245 > +#: appwiz.rc:66 > +#: appwiz.rc:42 > +#: cryptui.rc:343 > +#: msacm32.rc:37 > +#: winecfg.rc:191 > +#: winecfg.rc:228 > +#: wordpad.rc:245 > msgid "&Remove" > msgstr "Odeb&rat" --- This adds a lot of diff lines that you don't really want.

July 1, 2013

Re: [PATCH] advapi32: RegDeleteKey tests for merged view of HKCR

by wine.dev＠web.de

Hi George. > [PATCH] advapi32: RegDeleteKey tests for merged view of HKCR > http://newtestbot.winehq.org/JobDetails.pl?Key=1403 > --- > dlls/advapi32/tests/registry.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) I can't test atm, but it looks good while reading. Please add a [try 2] to the subject and send it to wine-patches. -- Detlef

July 1, 2013

Re: [RFC PATCH] loader: allow overriding pthread_create correctly on linux

by Austin English

On Fri, Jun 28, 2013 at 3:53 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > This should be enough to fix bug #30557 in the most thorough possible way. > Only tested on ubuntu precise 32-bits atm, but I believe it should work on 64-bits too. > > TODO: pthread_create_2_0 is not handled correctly right now, so it will fail on ancient glibc's < 2.2. > But because NPTL requires a slightly newer glibc than that I do not believe it will be a real issue. > > Comments welcome :-) > --- > diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c > index 01a8026..e9775c3 100644 > --- a/dlls/ntdll/thread.c > +++ b/dlls/ntdll/thread.c > @@ -33,6 +33,7 @@ > #ifdef HAVE_SYS_SYSCALL_H > #include <sys/syscall.h> > #endif > +#include <errno.h> > > #define NONAMELESSUNION > #include "ntstatus.h" > @@ -58,6 +59,7 @@ struct startup_info > TEB *teb; > PRTL_THREAD_START_ROUTINE entry_point; > void *entry_arg; > + BOOL native_thread; > }; > > static PEB *peb; > @@ -186,6 +188,20 @@ done: > return status; > } > > +#ifdef __linux__ > +extern typeof(pthread_create) *__glob_pthread_create, *call_pthread_create; > +static typeof(pthread_create) __hook_pthread_create; > + > +static void thread_wrap_init(void) > +{ > + call_pthread_create = __hook_pthread_create; > +} > + > +#else > +#define __glob_pthread_create pthread_create > +#define thread_wrap_init() > +#endif > + > /*********************************************************************** > * thread_init > * > @@ -204,6 +220,7 @@ HANDLE thread_init(void) > struct ntdll_thread_data *thread_data; > static struct debug_info debug_info; /* debug info for initial thread */ > > + thread_wrap_init(); > virtual_init(); > > /* reserve space for shared user data */ > @@ -327,11 +344,7 @@ void terminate_thread( int status ) > pthread_exit( UIntToPtr(status) ); > } > > - > -/*********************************************************************** > - * exit_thread > - */ > -void exit_thread( int status ) > +static void exit_thread_common( int status ) > { > static void *prev_teb; > TEB *teb; > @@ -377,9 +390,60 @@ void exit_thread( int status ) > close( ntdll_get_thread_data()->wait_fd[1] ); > close( ntdll_get_thread_data()->reply_fd ); > close( ntdll_get_thread_data()->request_fd ); > +} > + > +void exit_thread( int status ) > +{ > + exit_thread_common(status); > pthread_exit( UIntToPtr(status) ); > } > > +#ifdef __linux__ > + > +struct unix_arg { > + void *(*start)(void *); > + void *arg; > +}; > + > +/* dummy used for comparison */ > +static DWORD native_unix_start; > + > +static void call_native_cleanup(void *arg) > +{ > + RtlFreeThreadActivationContextStack(); > + exit_thread_common(0); > +} > + > +static int > +__hook_pthread_create(pthread_t *thread, const pthread_attr_t *attr, > + void *(*start_routine) (void *), void *parm) > +{ > + NTSTATUS ret; > + struct unix_arg arg; > + arg.start = start_routine; > + arg.arg = parm; > + > + TRACE("Overriding thread creation!\n"); > + if (attr) > + FIXME("thread attributes ignored!\n"); > + > + ret = RtlCreateUserThread( NtCurrentProcess(), NULL, FALSE, NULL, 0, 0, (void*)&native_unix_start, &arg, NULL, (void*)thread ); > + if (ret != STATUS_SUCCESS) > + FIXME("ret: %08x\n", ret); > + switch (ret) { > + case STATUS_SUCCESS: > + return 0; > + case STATUS_NO_MEMORY: > + return ENOMEM; > + case STATUS_TOO_MANY_OPENED_FILES: > + return EMFILE; > + default: > + ERR("Unhandled ntstatus %08x\n", ret); > + return ENOMEM; > + } > +} > + > +#endif > > /*********************************************************************** > * start_thread > @@ -412,9 +476,18 @@ static void start_thread( struct startup_info *info ) > if (TRACE_ON(relay)) > DPRINTF( "%04x:Starting thread proc %p (arg=%p)\n", GetCurrentThreadId(), func, arg ); > > - call_thread_entry_point( (LPTHREAD_START_ROUTINE)func, arg ); > -} > +#ifdef __linux__ > + if (info->native_thread) { > + void *(*start)(void*) = (void*)func; > > + FIXME("Started native thread %08x\n", GetCurrentThreadId()); > + pthread_cleanup_push(call_native_cleanup, NULL); > + pthread_exit(start(arg)); > + pthread_cleanup_pop(1); > + } else > +#endif > + call_thread_entry_point( (LPTHREAD_START_ROUTINE)func, arg ); > +} > > /*********************************************************************** > * RtlCreateUserThread (NTDLL.@) > @@ -497,8 +570,18 @@ NTSTATUS WINAPI RtlCreateUserThread( HANDLE process, const SECURITY_DESCRIPTOR * > > info = (struct startup_info *)(teb + 1); > info->teb = teb; > - info->entry_point = start; > - info->entry_arg = param; > +#ifdef __linux__ > + info->native_thread = (void*)start == (void*)&native_unix_start; > + if (info->native_thread) { > + struct unix_arg *arg = param; > + info->entry_point = (void*)arg->start; > + info->entry_arg = arg->arg; > + } else > +#endif > + { > + info->entry_point = start; > + info->entry_arg = param; > + } > > thread_data = (struct ntdll_thread_data *)teb->SpareBytes1; > thread_data->request_fd = request_pipe[1]; > @@ -513,7 +596,7 @@ NTSTATUS WINAPI RtlCreateUserThread( HANDLE process, const SECURITY_DESCRIPTOR * > (char *)teb->Tib.StackBase - (char *)teb->DeallocationStack ); > pthread_attr_setscope( &attr, PTHREAD_SCOPE_SYSTEM ); /* force creating a kernel thread */ > interlocked_xchg_add( &nb_threads, 1 ); > - if (pthread_create( &pthread_id, &attr, (void * (*)(void *))start_thread, info )) > + if (__glob_pthread_create( &pthread_id, &attr, (void * (*)(void *))start_thread, info )) > { > interlocked_xchg_add( &nb_threads, -1 ); > pthread_attr_destroy( &attr ); > @@ -523,6 +606,11 @@ NTSTATUS WINAPI RtlCreateUserThread( HANDLE process, const SECURITY_DESCRIPTOR * > pthread_attr_destroy( &attr ); > pthread_sigmask( SIG_SETMASK, &sigset, NULL ); > > +#ifdef __linux__ > + if (native_thread && id) > + *(pthread_t*)id = pthread_id; > + else > +#endif > if (id) id->UniqueThread = ULongToHandle(tid); > if (handle_ptr) *handle_ptr = handle; > else NtClose( handle ); > diff --git a/dlls/winegstreamer/glibthread.c b/dlls/winegstreamer/glibthread.c > index 25eceb8..7417941 100644 > --- a/dlls/winegstreamer/glibthread.c > +++ b/dlls/winegstreamer/glibthread.c > @@ -43,6 +43,7 @@ > #include <stdlib.h> > #include <stdio.h> > > +#if 0 > #include "windef.h" > #include "winbase.h" > #include "winnls.h" > @@ -388,3 +389,15 @@ void g_thread_impl_init (void) > g_thread_self_tls = TlsAlloc (); > g_thread_init(&g_thread_functions_for_glib_use_default); > } > + > +#else > + > +void g_thread_impl_init (void) > +{ > + static gboolean beenhere = FALSE; > + > + if (!beenhere++) > + g_thread_init(NULL); > +} > + > +#endif > diff --git a/libs/wine/loader.c b/libs/wine/loader.c > index 094e5e1..69f4a38 100644 > --- a/libs/wine/loader.c > +++ b/libs/wine/loader.c > @@ -69,6 +69,11 @@ char **__wine_main_argv = NULL; > WCHAR **__wine_main_wargv = NULL; > char **__wine_main_environ = NULL; > > +#ifdef __linux__ > +#include <pthread.h> > +typeof(pthread_create) *call_pthread_create, *__glob_pthread_create; > +#endif > + > struct dll_path_context > { > unsigned int index; /* current index in the dll path list */ > diff --git a/libs/wine/wine.map b/libs/wine/wine.map > index 2159fac..694869a 100644 > --- a/libs/wine/wine.map > +++ b/libs/wine/wine.map > @@ -117,6 +117,8 @@ WINE_1.0 > wine_utf8_mbstowcs; > wine_utf8_wcstombs; > wine_wctype_table; > + __glob_pthread_create; > + call_pthread_create; > > local: *; > }; > diff --git a/loader/main.c b/loader/main.c > index ac67290..14b2428 100644 > --- a/loader/main.c > +++ b/loader/main.c > @@ -202,6 +202,27 @@ static int pre_exec(void) > > #endif > > +#ifdef __linux__ > + > +extern typeof(pthread_create) *call_pthread_create, *__glob_pthread_create; > + > +int pthread_create(pthread_t *thread, const pthread_attr_t *attr, > + void *(*start_routine) (void *), void *arg) > +{ > + return call_pthread_create(thread, attr, start_routine, arg); > +} > + > +static void init_thread_hook(void) { > + call_pthread_create = __glob_pthread_create = dlvsym(RTLD_NEXT, "pthread_create", "GLIBC_2.2"); > + if (!__glob_pthread_create) > + call_pthread_create = __glob_pthread_create = dlvsym(RTLD_NEXT, "pthread_create", "GLIBC_2.1"); > +} > + > +#else > + > +#define init_thread_hook() > + > +#endif > > /********************************************************************** > * main > @@ -211,6 +232,8 @@ int main( int argc, char *argv[] ) > char error[1024]; > int i; > > + init_thread_hook(); > + > if (!getenv( "WINELOADERNOEXEC" )) /* first time around */ > { > static char noexec[] = "WINELOADERNOEXEC=1"; Fails to compile here (as mentioned on bug 30557): gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -o thread.o thread.c thread.c: In function ‘RtlCreateUserThread’: thread.c:610:9: error: ‘native_thread’ undeclared (first use in this function) thread.c:610:9: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [thread.o] Error 1 make[1]: Leaving directory `/home/austin/wine-git/dlls/ntdll' make: *** [dlls/ntdll] Error 2 I tried Ruslan's fixed patch, which failed as well: gcc -m32 -c -I. -I. -I../include -I../include -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -g -O2 -fno-builtin -o main.o main.c gcc -m32 -o wine -Wl,--export-dynamic -Wl,--section-start,.interp=0x7bf00400 main.o -L../libs/wine -lwine ../libs/port/libwine_port.a -lpthread -Wl,--rpath,\$ORIGIN/../libs/wine /usr/bin/ld: main.o: undefined reference to symbol 'dlvsym@@GLIBC_2.1' /usr/bin/ld: note: 'dlvsym@@GLIBC_2.1' is defined in DSO /lib/libdl.so.2 so try adding it to the linker command line /lib/libdl.so.2: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[1]: *** [wine] Error 1 make[1]: Leaving directory `/home/austin/wine-git/loader' make: *** [loader] Error 2 this is 32-bit wine on fedora 64 (against 1.6-rc4). -- -Austin

July 1, 2013