Bug 53661 - 'mcopy -t' adds \032 at the end of file
'mcopy -t' adds \032 at the end of file
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: mtools (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-14 05:17 EDT by giulioo
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-09-21 06:45:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description giulioo 2001-09-14 05:17:16 EDT
Description of problem:

When you copy a unix file to "a:" using "-t" to convert unix->dos, all
\n are correctly converted to \r\n, but a \032 is added at the end of file.

If you then copy the file back using "-t" from "a:" to linux, then the 032 
is taken out and you get a file identical to the original one, but if you 
use the file on "a:" in dos/win (or you copy it back to linux without -t) 
you see the 032 as an unprintable char.

Version-Release number of selected component (if applicable):
mtools-3.9.8-2

How reproducible:
Always

Steps to Reproduce:
This was actually tested on rh6x with a rebuilt mtools src.rpm from enigma.

$ rpm -q mtools
mtools-3.9.8-2
$ grep "a:" /etc/mtools.conf|grep -v "^#"
drive a: file="/dev/fd0" exclusive mformat_only
$ echo "This is a test" > file1
$ od -bc file1
0000000 124 150 151 163 040 151 163 040 141 040 164 145 163 164 012
          T   h   i   s       i   s       a       t   e   s   t  \n
0000017
$ ls -l file1
-rw-rw----   1 cdi      cdi            15 Sep 14 11:19 file1
$ mcopy -t file1 a:
$ mdir a:|grep file1
file1               17 09-14-2001  11:19     <=== *** 2 bytes added ***
$ mcopy a:file1 file2 (w/o -t to get raw file, like dos/win would do)
$ od -bc file2
0000000 124 150 151 163 040 151 163 040 141 040 164 145 163 164 015 012
          T   h   i   s       i   s       a       t   e   s   t  \r  \n
0000020 032
        032
0000021
$


Actual Results:  \032 is added at the end of file

Expected Results:  Just \n -> \r\n conversion should happen
Comment 1 giulioo 2001-09-21 06:45:54 EDT
Latest patch mtools-3.9.8-20010908.diff.gz does not help.
I'm writing to mtools mailing list.
Comment 2 giulioo 2001-10-05 05:44:35 EDT
It seems that:
- \032 / Ctrl-Z was needed by CP/M as EOF marker
- dos wanted to be compatible and managed a final Ctrl-Z well, but it did not 
need it at all
- recent dos/win progs do not handle Ctrl-Z well (notepad.exe show it as an 
unprintable char)
- it would be useful for mtools not to write Ctrl-Z when doing unix-> dos, and 
to handle an eventual Ctrl-Z when doing dos->unix
- mtools author does not care, he just says "drop -t option" (for 4 times I 
explained to him that I needed to put unix files on a floppy to be read with 
notepad.exe, and that i didn't want to see an unprintable char)
- a quick hack to fix the problem is this
--- mcopy.c.orig    Thu Oct  4 20:49:48 2001
+++ mcopy.c Thu Oct  4 20:50:15 2001
@@ -297,9 +297,11 @@
    ret = copyfile(arg->mp.File, Target);
    GET_DATA(Target, 0, &newsize, 0, &fat);
    FREE(&Target);
+#if 0
    if (arg->needfilter & arg->textmode)
        newsize++; /* ugly hack: we gathered the size before the Ctrl-Z
            * was written.  Increment it manually */
+#endif
    if(ret < 0 ){
        fat_free(arg->mp.targetDir, fat);
        return -1;
This leaves mcopy adding ctrl-Z (in filter.c), but truncates the file before 
the ctrl-Z.

So, since the author considers this behavior as "by design", I'm closing this 
as not a bug.

Note You need to log in before you can comment on or make changes to this bug.