[Bug 37637] New: CreateNamedPipe, ReadFile, PIPE_WAIT or BufferSize problem
https://bugs.winehq.org/show_bug.cgi?id=37637 Bug ID: 37637 Summary: CreateNamedPipe, ReadFile, PIPE_WAIT or BufferSize problem Product: Wine Version: 1.7.30 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: den.aria(a)gmail.com Distribution: --- I have problem in Wine when reading data from NamePipe, when data is bigger than 36672. 1 Create Pipe hPipe := CreateNamedPipe(Name, PIPE_ACCESS_DUPLEX, PIPE_WAIT or PIPE_TYPE_BYTE or PIPE_READMODE_BYTE, MAX_PIPE_INSTANCES, 0,//MAX_WRITE, 0,//MAX_READ, TIME_OUT, @sa);
PIPE_WAIT MAX_WRITE and MAX_READ can be random value, from 0 > 999999999
2 Reading data if not ReadFile(APipe, msData.Memory^, cBuffer, cBytesRead, nil) then begin Exit; end; I got result True but not all data is read. cBuffer > cBytesRead, ( cBytesRead = 36672 maximum) I need do loop for reading all data from PIPE. --------- In windows i don't have this problem. Help me. :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 --- Comment #1 from Bruno Jesus <00cpxxx(a)gmail.com> --- Dup of bug 17195? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|kernel32 |-unknown -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #2 from Sebastian Lackner <sebastian(a)fds-team.de> --- Doesn't sound like a duplicate, but more like the assumption that the buffer size is big enough. I don't think that Windows give a guarantee that it will work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 --- Comment #3 from den123 <den.aria(a)gmail.com> --- No, i don't think that. May be problem in PIPE_WAIT flag. I use synchronize Pipe mode and i must get result true when all data is read, but i get result True of reading operation before all data is read, like in PIPE_NOWAIT mode. In windows is work ok. P.S PIPE_WAIT 0x00000000 Blocking mode is enabled. This mode is the default if no wait-mode flag is specified. When a blocking mode pipe handle is specified in the ReadFile, WriteFile, or ConnectNamedPipe function, operations are not finished until there is data to read, all data is written, or a client is connected. Use of this mode can mean waiting indefinitely in some situations for a client process to perform an action. Client to PIPE code hPipe := CreateFile(PChar(Named), GENERIC_WRITE or GENERIC_READ, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, 0, 0); if not WriteFile(hPipe, msData.Memory^, cBuffer, cBytesWritten, nil) then Exit; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #4 from Jacek Caban <jacek(a)codeweavers.com> --- Created attachment 58650 --> https://bugs.winehq.org/attachment.cgi?id=58650 patch This problem should not exist when using server-side named pipe I/O implementation. Currently we use it only for message mode. The attached patch implements it for byte mode as well. It should fix this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |7eb785416193f7ca154872222b9 | |cfcd3db7a7418 Resolution|--- |FIXED --- Comment #5 from Jacek Caban <jacek(a)codeweavers.com> --- Fixed in Git. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 2.19. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=37637 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Component|-unknown |wineserver -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla