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
Latest patch mtools-3.9.8-20010908.diff.gz does not help. I'm writing to mtools mailing list.
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.