http://bugs.winehq.org/show_bug.cgi?id=9809
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #4 from Anastasius Focht focht@gmx.net 2007-11-13 17:11:25 --- Hello,
ran into same issue in AutoCAD 2008 installer.
Well, MSDN says following to this multi-paths buffers (http://msdn2.microsoft.com/en-us/library/bb759795.aspx):
--- snip --- A pointer to one or more source file names. These names should be fully-qualified paths to prevent unexpected results.
Standard Microsoft MS-DOS wildcard characters, such as "*", are permitted only in the file-name position. Using a wildcard character elsewhere in the string will lead to unpredictable results.
Although this member is declared as a single null-terminated string, it is actually a buffer that can hold multiple null-delimited file names. Each file name is terminated by a single NULL character. The last file name is terminated with a double NULL character ("\0\0") to indicate the end of the buffer. --- snip ---
Same applies for "lpFileOp->pTo" member. The wide character version must have at least 4 null bytes appended to indicate end of list.
I hex dumped the buffers from SHFileOperationW:
--- snip lpFileOp->pFrom ---
5A003A00 5C006D00 6E007400 5C006900< Z.:..m.n.t..i. 00000000 73006F00 5C002A00 2E006500 78006500< s.o..*...e.x.e. 00000010 00000000 49006100 2E007400 6D007000< ....I.a...t.m.p. 00000020 00000000 00004E00 5F004300 4F004F00< ......N._.C.O.O. 00000030 4B004900 45003D00 65006500 32003300< K.I.E.=.e.e.2.3. 00000040
--- snip lpFileOp->pFrom ---
--- snip lpFileOp->pTo ---
43003A00 5C007700 69006E00 64006F00< C.:..w.i.n.d.o. 00000000 77007300 5C007400 65006D00 70005C00< w.s..t.e.m.p.. 00000010 5F004100 49006100 2E007400 6D007000< _.A.I.a...t.m.p. 00000020 5C000000 18000000 55534500 A4370510< .......USE..7.. 00000030
--- snip lpFileOp->pTo ---
From the technical standpoint it's a bug in their installer because even if
they supply only _one_ path in lpFileOp->pTo it must be double (wide) NULL terminated.
After some debugging I found a workable solution. It seems in windows if FOF_MULTIDESTFILES is NOT set in lpFileOp->fFlags (set flag means that lpFileOp->pTo can contain multiple destination file names) this condition has precedence over multi-path splitting.
Just give dlls/shell32/shlfileop.c:parse_file_list() a hint to break loop if not "multi" (based on FOF_MULTIDESTFILES flag). This allows broken apps which supply non double NULL terminated lpFileOp->pTo to continue (no FOF_MULTIDESTFILES set -> process only one path/iteration -> break loop).
Regards