noelroy@kean.mun.ca (Noel Roy, Economics Dept., Memorial University) (10/18/89)
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. As a result, RESTORE does not recognize the diskette as valid, and aborts. This corruption occurs even after a clean boot, with no resident programs. When the system date is reset to September, the corruption does not occur. The patch to BACKUPID.@@@ is fairly trivial, but a nuisance nevertheless. Has anyone else noticed this problem? Is this a bug in BACKUP.COM, or do I have system problems? _________________________________________________________________________ | | | Dr. Noel Roy | | Room A3048 Phone (709) 737-8245/8 | | Department of Economics FAX (709) 737-4569 | | Memorial University of Newfoundland | | St. John's, Newfoundland A1C 5S7 Canada | |-----------------------------------------------------------------------| | bitnet: NOELROY@MUN | | internet: noelroy%kean.mun.ca@CORNELLC.cit.cornell.edu | | cdnnet: noelroy@kean.mun.cdn | | uunet: noelroy@munucs.UUCP | | o o | | icbmnet: lat 47 34'6"N long 52 44'8"W alt 69m | |_______________________________________________________________________|
Ralf.Brown@B.GP.CS.CMU.EDU (10/19/89)
In article <2576@dogie.macc.wisc.edu>, michaelb@vms.macc.wisc.edu (Michael Bloxham) wrote: >>Has anyone else noticed this problem? Is this a bug in BACKUP.COM, >>or do I have system problems? > >I have heard from my contacts at Zenith that there may be either a bug or >virus in ZENITH DOS 3.3+ RESTORE.COM. This was sent to me via a email Having the byte that is supposed to be 0Ah turn up as 0Dh 0Ah indicates to me that the programmer forgot to make the "C" program write to the file in binary mode (the above is precisely the NL -> CRLF translation MSDOS "C" libraries perform in text mode). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? "How to Prove It" by Dana Angluin 1. proof by example: The author gives only the case n=2 and suggests that it contains most of the ideas of the general proof
michaelb@vms.macc.wisc.edu (Michael Bloxham) (10/20/89)
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. > [stuff deleted] > >Has anyone else noticed this problem? Is this a bug in BACKUP.COM, >or do I have system problems? > I have heard from my contacts at Zenith that there may be either a bug or virus in ZENITH DOS 3.3+ RESTORE.COM. This was sent to me via a email message from a tech support guy at Zenith. Along with the message was attached a copy of RESTORE.COM which was supposed to be clean. I am not clear as to whether it is just a bug in the programming, or an actual virus infected restore.com from the ZENITH factory. I don't use DOS's backup and restore, but rather FASTBACK+, so I never really looked into it. I do have a copy of the 'good' RESTORE.COM at work. If you would like, I'll try emailing you this good copy. good luck, mike ----------------------------------------------------------------------- Michael L. Bloxham | Real programmers don't comment their code. michaelb@vms.macc.wisc.edu | If it was hard to write, it should be hard michaelb@WISCMACC.bitnet | to understand.
noelroy@kean.mun.ca (Noel Roy, Economics Dept., Memorial University) (10/20/89)
In article <2576@dogie.macc.wisc.edu>, michaelb@vms.macc.wisc.edu (Michael Bloxham) writes: > 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. >> > [stuff deleted] >> >>Has anyone else noticed this problem? Is this a bug in BACKUP.COM, >>or do I have system problems? >> > > I have heard from my contacts at Zenith that there may be either a bug or > virus in ZENITH DOS 3.3+ RESTORE.COM. This was sent to me via a email > message from a tech support guy at Zenith. Along with the message was > attached a copy of RESTORE.COM which was supposed to be clean. I am not > clear as to whether it is just a bug in the programming, or an actual virus > infected restore.com from the ZENITH factory. > > I do have a copy of the 'good' RESTORE.COM at work. If you would like, > I'll try emailing you this good copy. > > good luck, > mike > ----------------------------------------------------------------------- It is definitely a problem with BACKUP.COM, not RESTORE.COM, since the backup disks get corrupted even before a RESTORE attempt. Possibly RESTORE has been modified by ZENITH to ignore the corrupted bytes. I would appreciate your sending me the file. UUDECODED is fine. Regards/Noel _________________________________________________________________________ | | | Dr. Noel Roy | | Room A3048 Phone (709) 737-8245/8 | | Department of Economics FAX (709) 737-4569 | | Memorial University of Newfoundland | | St. John's, Newfoundland A1C 5S7 Canada | |-----------------------------------------------------------------------| | bitnet: NOELROY@MUN | | internet: noelroy%kean.mun.ca@CORNELLC.cit.cornell.edu | | cdnnet: noelroy@kean.mun.cdn | | uunet: noelroy@munucs.UUCP | | o o | | icbmnet: lat 47 34'6"N long 52 44'8"W alt 69m | |_______________________________________________________________________|
Wes@cup.portal.com (Wes H Cowley) (10/21/89)
> I seem to be getting contaminated BACKUPID.@@@ files on my DOS BACKUP > diskettes. I am running DOS version 3.3+, from Zenith. > The size of the file increases to 129. Yes. This is a bug in Zenith's 3.3+ Backup. I ran into it the first weekend in October. The problem is apparently that Backup is opening the file in text mode causing translation of LF's to CR/LF's. October is coded as an LF. The same problem will occur on the 10th of any month. The fix is trivial. Open the file in text mode, read the file in, delete the file, create it in binary mode, then dump the data back out. I will email you the source to the program I wrote to fix the backups. If anyone else needs it let me know, I'll be happy to email the source to you. Wes Cowley wes@cup.portal.com PO BOX 280138 Tampa, FL 33682-0138
mikey@shuksan.UUCP (Mike Fields) (10/24/89)
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