JLI@VAX.OXFORD.AC.UK (James Li, Oxford) (08/18/90)
Dear netter,
I have lost the contents of two floppies after copying some files
into them on a ibm compatible in the computing service in Oxford.
After copying I got information about one of the floppies as follows:
from dos command "dir":
Volume in drive A is |s$;n
Directory of A:\
kPC To ols 12255232 9-00-80 12:00a
|3@zP c $X871598879 25-05-80 12:04p
`
hl >l <DIR> 12-07-81 8:30p
Ahv
ZYFl2767453438 30-05-75 12:02a
6 File(s) 12288 bytes free
from dos command chkdsk:
Volume |s$;n created 26 Wri 2069 9:30p
Errors found, F parameter not specified.
Corrections will not be written to disk.
A:\kPC To.ols
Allocation error, size adjusted.
A:\|3@zP c.$X
First cluster number is invalid,
entry truncated.
A:\|s$;n
First cluster number is invalid,
entry truncated.
Cannot CHDIR to A:\>_W=
tree past this point not processed.
A:\`
First cluster number is invalid,
entry truncated.
A:\Ms2dM.Mur
First cluster number is invalid,
entry truncated.
A:\tC i
First cluster number is invalid,
entry truncated.
A:\:6j
First cluster number is invalid,
entry truncated.
A:\hl.>l
First cluster number is invalid,
entry truncated.
A:\Ahv
First cluster number is invalid,
entry truncated.
A:\&?J
First cluster number is invalid,
entry truncated.
A:\i
First cluster number is invalid,
entry truncated.
A:\ZYFl
First cluster number is invalid,
entry truncated.
A:\^Aho^;
First cluster number is invalid, entry truncated.
132 lost clusters found in 10 chains.
Convert lost chains to files (Y/N)? n
135168 bytes disk space
would be freed.
362496 bytes total disk space 0 bytes in 6 hidden files
4096 bytes in 4 directories
210944 bytes in 5 user files
12288 bytes available on disk
654336 bytes total memory
543600 bytes free
However, when using scanv64 on these floppies, I got the report as "no
virus found". I was puzzled about this situation. Could anyone can
tell me what may have happened to the floppies? Are these floppies
infected or not? Is there any chance to recover the contents on the
floppies? I will appreciate any help on this problem.
James LiWatkins@np1a.bristol.ac.uk (Steff) (08/22/90)
With response to James Li (Uk.AC.OXFORD) .... It looks like you have had a case of INT 26 (I Believe) calls. This causes an absolute disk-write of some area of preogram memory onto the disk. I believe this to be so, as when I was exercising some assembler code a few weeks ago, I made the mistake of entering an INT 26H call instead of an INT 21H call, and the result was a very-unusable floppy (which was a work-diskette fortunately!!). On obtaining a directory of the diskette, I received a similar result to what you have described. I would therefore suggest that either A> Some of your source code contains an INT 26H call that it shouldn't. B> Some of your coding has gone terminally ill. It could always be a virus, tho.... ******************************************************************************** * Steff Watkins B.Sc., Computer Operations Officer, Bristol University * * Address (Work) :- Computing Centre, Tyndall Avenue, Bristol BS8 1UD * * Telephone (Voice):- (0272) 303030 Extn:- 3042 or 4531 * * Telephone (Fax) :- (0272) 291576 * * E-Mail :- Steff.Watkins@UK.AC.BRISTOL.NP1A * ********************************************************************************
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/26/90)
James Li posts a message about trashed disks. o.k., I would say that you have no infected disks, but what has happened is fairly nasty. I am assuming that you formatted the disks on the other machine. Now, there are various flavors of DOS around, and various flavors of format utilities. If you take a disk formatted and written on by dos 3.x and try reading it on a system running dos 2.1x you will have symptoms exactly as described. MS-DOS is only upwardly compatable between major releases, i.e. primary number changes. There is an additional problem. We released a new software package where I work. Some of our users reported that file directories were garbaged out and the programs would not work, others had no problem. I got a set of bad disks sent back. On my machine they were trashed, on a compaq they were trashed, on another machine, running another flavor of DOS, they were fine. A perusal with Norton, revealed the following: In the FAT table (the File Allocation Table) the first byte used to be used as a format identifier. If it was a F0 it marked a single sided 180k floppy. If it is F8 it is a double sided 360K floppy. The format program out on the factory floor was formatting double sided, but writing the id byte for a single sided disk. Some versions of dos make decisions based on the FAT table, others use other criteria to determine what kind of disk it is. Those that used other critera, such as placement of FAT tables worked, the ones that used the id byte didnot. MS documentation says that the id byte can no longer be relied on. The basic problem is that the first copy of the FAT always resides at the same spot both for 360k and 180k floppies, but in the case of a 360k floppy, the fat table is 2 'x as big. The second sector of the second fat table, occupies (on a 360K disk) occupies the exact same physical/logical sector as the directory sector on a 180K floppy. This results in total hash in the directory if the system thinks it's a 180K floppy. Hope this helps Cheers Woody
woody@chinacat.Unicom.COM (Woody Baker @ Eagle Signal) (08/26/90)
Watkins@np1a.bristol.ac.uk (Steff) writes: > With response to James Li (Uk.AC.OXFORD) .... > > It looks like you have had a case of INT 26 (I Believe) calls. This causes an > absolute disk-write of some area of preogram memory onto the disk. > A> Some of your source code contains an INT 26H call that it shouldn't. MSDOS 4.x has monkeyed around rather severly with the int 25 and int 226 call If the CX register is ffff (an illegal value under dos 3.x) it presumes that the registers are used diffrently in order to support the new 32 bit fat table. This may cause severe system crashes and file corruptions. Cheers Woody