This should fix the remaining issues in bug #16214.
From: Joe Souza jsouza@yahoo.com
--- programs/cmd/builtins.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c index 78ef855d099..9a5a4ffac4f 100644 --- a/programs/cmd/builtins.c +++ b/programs/cmd/builtins.c @@ -555,8 +555,8 @@ static BOOL WCMD_ManualCopy(WCHAR *srcname, WCHAR *dstname, BOOL ascii, BOOL app BOOL ok; DWORD bytesread, byteswritten;
- WINE_TRACE("Manual Copying %s to %s (append?%d)\n", - wine_dbgstr_w(srcname), wine_dbgstr_w(dstname), append); + WINE_TRACE("Manual Copying %s to %s (ascii: %u) (append: %u)\n", + wine_dbgstr_w(srcname), wine_dbgstr_w(dstname), ascii, append);
in = CreateFileW(srcname, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); @@ -1006,7 +1006,10 @@ RETURN_CODE WCMD_copy(WCHAR * args) if (wcsncmp(srcpath, L"\\.\", lstrlenW(L"\\.\")) == 0) { WINE_TRACE("Source is a device\n"); srcisdevice = TRUE; - srcname = &srcpath[4]; /* After the \.\ prefix */ + srcname = &srcpath[4]; /* After the \.\ prefix */ + if (!wcsnicmp(srcname, L"CON", 3)) { + thiscopy->binarycopy = FALSE; + } } else {
/* Loop through all source files */ @@ -1095,15 +1098,9 @@ RETURN_CODE WCMD_copy(WCHAR * args) } else status = FALSE; } else if (anyconcats && writtenoneconcat) { - if (thiscopy->binarycopy) { - status = WCMD_ManualCopy(srcpath, outname, FALSE, TRUE); - } else { - status = WCMD_ManualCopy(srcpath, outname, TRUE, TRUE); - } - } else if (!thiscopy->binarycopy) { - status = WCMD_ManualCopy(srcpath, outname, TRUE, FALSE); - } else if (srcisdevice) { - status = WCMD_ManualCopy(srcpath, outname, FALSE, FALSE); + status = WCMD_ManualCopy(srcpath, outname, !thiscopy->binarycopy, TRUE); + } else if (!thiscopy->binarycopy || srcisdevice) { + status = WCMD_ManualCopy(srcpath, outname, !thiscopy->binarycopy, FALSE); } else { status = CopyFileW(srcpath, outname, FALSE); }
(Dont have access to a dev box, so only asking questions) - what behavior are fixed by this MR? - which interactive tests did you perform with/without this MR ? - does copy /b con foo uses the ascii mode ? - does the new behavior of changing copy mode for CON applies to other devices ?
On Thu Aug 28 17:38:52 2025 +0000, eric pouech wrote:
(Dont have access to a dev box, so only asking questions)
- what behavior are fixed by this MR?
- which interactive tests did you perform with/without this MR ?
- does copy /b con foo uses the ascii mode ?
- does the new behavior of changing copy mode for CON applies to other
devices ?
* what behavior are fixed by this MR? ^Z does not terminate a copy of text from the console device.
* which interactive tests did you perform with/without this MR ? copy con tmp.txt copy con: tmp.txt copy con:s tmp.txt copy /b con tmp.txt
In each case above, text was entered, followed by ^Z.
copy nul tmp.txt copy nul: tmp.txt
Both of these cases also worked as expected.
* does copy /b con foo uses the ascii mode ? Native Win10 appears to force ASCII mode for 'copy con' even if /b were specified. ^Z still terminated the copy operation.
* does the new behavior of changing copy mode for CON applies to other devices ? That's an interesting question. My best answer is no. LPTx is an output device. COMx perhaps, although these are mainly configured via MODE, and I don't have a good way to test that functionality. Should be easy to add an additional device name comparison in the future if it is found to be needed.
On Sat Aug 30 11:46:33 2025 +0000, Joe Souza wrote:
- what behavior are fixed by this MR?
^Z does not terminate a copy of text from the console device.
- which interactive tests did you perform with/without this MR ?
copy con tmp.txt copy con: tmp.txt copy con:s tmp.txt copy /b con tmp.txt In each case above, text was entered, followed by ^Z. copy nul tmp.txt copy nul: tmp.txt Both of these cases also worked as expected.
- does copy /b con foo uses the ascii mode ?
Native Win10 appears to force ASCII mode for 'copy con' even if /b were specified. ^Z still terminated the copy operation.
- does the new behavior of changing copy mode for CON applies to other
devices ? That's an interesting question. My best answer is no. LPTx is an output device. COMx perhaps, although these are mainly configured via MODE, and I don't have a good way to test that functionality. Should be easy to add an additional device name comparison in the future if it is found to be needed.
Thanks for the answers. A) I was wondering if there were a specific handling for devices vs per device specific behaviors. As copy /b com1 is handled in binary whereas copy /b con isn't (and assuming you did test "copy /b con foo" and not "copy con foo /b"), keeping per device behavior looks a good choice. B) For the tests I would add: Copy /a con+in out Copy /a in+con out Copy /b con+in out Copy /b in+con out Copy con+in out Copy in+con out Where in is a file containing a ctrl-z, and checkin in out file the final result (just to be sure that forcing ascii for con has no impact on prev/next copied files)
On Sat Aug 30 17:01:29 2025 +0000, eric pouech wrote:
Thanks for the answers. A) I was wondering if there were a specific handling for devices vs per device specific behaviors. As copy /b com1 is handled in binary whereas copy /b con isn't (and assuming you did test "copy /b con foo" and not "copy con foo /b"), keeping per device behavior looks a good choice. B) For the tests I would add: Copy /a con+in out Copy /a in+con out Copy /b con+in out Copy /b in+con out Copy con+in out Copy in+con out Where in is a file containing a ctrl-z, and checkin in out file the final result (just to be sure that forcing ascii for con has no impact on prev/next copied files)
I ran each of the tests that you specified, on both native Win10 and Wine with my changes. Behaviour seems correct. In cases where /b was specified, the ^Z character was preserved in the output file. In cases where /b was not specified, the ^Z character did not exist in the output file. Behaviour on both Win10 and Wine were the same. In no case was the ^Z character removed from the input file.
I did discover a new bug with the TYPE command. On Win10, TYPE terminates output at the ^Z character. Wine outputs the ^Z character and continues to output the remaining characters until the end of the file.
On Sat Aug 30 17:01:29 2025 +0000, Joe Souza wrote:
I ran each of the tests that you specified, on both native Win10 and Wine with my changes. Behaviour seems correct. In cases where /b was specified, the ^Z character was preserved in the output file. In cases where /b was not specified, the ^Z character did not exist in the output file. Behaviour on both Win10 and Wine were the same. In no case was the ^Z character removed from the input file. I did discover a new bug with the TYPE command. On Win10, TYPE terminates output at the ^Z character. Wine outputs the ^Z character and continues to output the remaining characters until the end of the file.
I have a fix for the TYPE issue ready to go after this MR is approved.
This merge request was approved by eric pouech.
On Sat Aug 30 18:16:50 2025 +0000, Joe Souza wrote:
I have a fix for the TYPE issue ready to go after this MR is approved.
Good.
Note that you could either extend this mr with the type modification (at the risque that new bits generate new comments and délai the acceptation) or if the two mr don't overlap (which is likely the case here) post the second mr in parallel of first.
Note also that there s an open ticket in bugzilla regarding TYPE command and binary files.
Test cases would be good to have too.
-
eric pouech (＠epo) -
Joe Souza
-
Joe Souza (＠JoeS209)