From: kortink@cs.utwente.nl (John Kortink)
Subject: Bug alert : RO3.1 corrupts DOS files
Organization: University of Twente, Dept. of Computer Science
Date: Mon, 9 Nov 1992 00:24:05 GMT

Serious RISCOS 3.1 bug alert !

This concerns copying files to DOS floppies with background operations on,
which can corrupt files.

Extensive bug hunt story following, which might help Acorn in killing this
bug before it kills them (I guess schools will go apeshit over this, as
it causes pure data loss !).

While copying a few graphics files from Archimedes to my MSDOS box, this
incredibly obscure and potentially very dangerous bug manifested itself.
My zippy hardware PC link not being available due to it being taken out
for other hardware development I resorted to using a floppy to transfer
the files.

The resulting JPEG files, after copy from Arc to floppy and then from floppy
to PC, were all correct, except two, which showed a strange 'Premature EOF'
error. Checking the lengths on both sides confirmed they were exactly equal
size. Then *DUMPing revealed that the last few bytes of the resulting DOS
files were definately corrupted.

Repeating the copy, and, prior to porting over the floppy, copying the file
off the DOS floppy again on the Arc (i.e. on, and off again), revealed ...
no errors ! Weird. *Then* putting the floppy in the DOS machine and copying
the file revealed ... no errors ! Being used to these 'can't happen' bugs,
I managed to remain calm and think a bit. Then, being curious, I repeated
the 'on Arc to floppy, eject, insert in DOS, copy' procedure, which
revealed ... no errors ! Wow, now I really must be slipping, thinketh I.

But, getting a vague suspicion (having written file buffer handling
routines for several of my apps), I repeat this with a different length
file. Yep. Corrupted. The why is now immediately apparent : as was my
suspicion, the mysterious 'ok again' file was not really ok, it just
happened to look that way on disc, because it happened to be written
over a correct copy. It must have been the last part missing the first
time.

Another test proved this. But why only these two ? Obviously something to
do with filelength. So I started testing and watching the background copy
counters. After a large number of tries, it seems that small files with
length mod 4096 <= 256 are consistently being corrupted, and not when >256.
This does not explain my &1FCEC file consistently being corrupted, but
watching the progress counters reveals that for long files the counter
appears to decrement by varying block sizes. Nevertheless, at least every
time the last block shows 256 bytes or less, the corruption occurs.

Corruption in these cases extends, as far as I can see, to the last 256
byte block. This is *not* written to disc and contains old garbage.

Further experimentation with rereading on Arc before porting the floppy,
and doing *Dismounts at different times, reveals that both seem to cause
the missing small data chunk (obviously still buffered by the FS) to be
written to the disc, while removing the disc (waiting till light off)
without doing either consistently corrupts these special length files.
Fully resetting the machine before doing either also shows the corruption
on re-reading the files on the Arc. Definately something wrong in the
'clean up' or 'update file to media' department.

Having seen the match between the 'to go' bytes counter and the corrupted
part, I then tried non-multitasking copy. This works all the time and does
not corrupt the files.

Experimentation with ADFS discs reveals that ADFS (thank God !) does *not*
suffer from data corruption in the same special cases. Must be DOSFS.

E.g. what we have here is certain corruption that occurs when writing files
with a specific length to DOS floppy (possibly with a specific configuration
resulting in specific buffer sizes etc., I don't know, Acorn does), and
*not* dismounting or re-accessing the floppy (which is usual, hands up
everybody who always dismounts each and every floppy before removal), and
then removing it to be read on another machine.

Over to you, Acorn. What's your excuse ? This is bloody dangerous !


John Kortink

Student of Informatics at the University of Twente, The Netherlands
(God, will I ever stop doing things 'on the side' and get it done?)
NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
Newsgroups: comp.sys.acorn