Bug 53661
| Summary: | 'mcopy -t' adds \032 at the end of file | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | giulioo |
| Component: | mtools | Assignee: | Bernhard Rosenkraenzer <bero> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.3 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-09-21 10:45:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
|
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