Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!uw-beaver!fluke!ssc-vax!shuksan!mikey
From: mikey@shuksan.UUCP (Mike Fields)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Corrupted BACKUP disks running MS-DOS 3.3
Summary: DOS backup bug??
Message-ID: <1593@shuksan.UUCP>
Date: 23 Oct 89 20:12:19 GMT
References: <21856@kean.mun.ca>
Organization: The Boeing Co., BAC MMST, Seattle, WA
Lines: 41

In article <21856@kean.mun.ca>, noelroy@kean.mun.ca (Noel Roy, Economics Dept., Memorial University) writes:
> I seem to be getting contaminated BACKUPID.@@@ files on my DOS BACKUP 
> diskettes.  I am running DOS version 3.3+, from Zenith.
> 
> Symptoms are as follows:  normally, BACKUPID.@@@ is a file of 128 
> bytes, with the last 122 padded with zeroes.  The first six bytes 
> contain information on date written, diskette number, and whether the 
> diskette is full.
> 
> The sixth byte (the one immediately before the padded zeroes) contains 
> the month in hexadecimal.  It was working fine through November 
> (months 01 through 09).  Beginning in October, instead of writing 0A, 
> it writes 0D 0A, and then adds the zeroes.  The size of the file 
> increases to 129.



I have a sneaky suspicion ---  The 0D 0A pair is an ascii CR LF pair --
I have seen this type of problem before with print routines that just
have to "help you" by making the simple LF (or CR) into the CRLF pair.
That is just fine if indeed you are writing those chars BUT if you are
trying to do cursor positioning etc and the 0A is the col, or row and
the system "Helps" you, there is this strange behaviour when the row or
col is just the right number!!

news -fodder


news -fodder
news -fodder
news -fodder
news -fodder
news -fodder
news -fodder
news -fodder

-- 
Mikey (yes "he likes it!")
=======================================================   Mike Fields
uw-beaver!ssc-vax!shuksan!mikey  (206) 393-3768 [work]    12022 NE 138th Pl.
(alt) ssc-vax!mikey              (206) 821-3492 [home]    Kirkland, Wa. 98034