home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / acorn / 9435 < prev    next >
Encoding:
Text File  |  1992-11-08  |  4.5 KB  |  92 lines
  1. Newsgroups: comp.sys.acorn
  2. Path: sparky!uunet!mcsun!sun4nl!utrcu1!infnews!kortink
  3. From: kortink@cs.utwente.nl (John Kortink)
  4. Subject: Bug alert : RO3.1 corrupts DOS files
  5. Message-ID: <1992Nov9.002405.5422@cs.utwente.nl>
  6. Sender: usenet@cs.utwente.nl
  7. Nntp-Posting-Host: utis96
  8. Organization: University of Twente, Dept. of Computer Science
  9. Date: Mon, 9 Nov 1992 00:24:05 GMT
  10. Lines: 80
  11.  
  12. Serious RISCOS 3.1 bug alert !
  13.  
  14. This concerns copying files to DOS floppies with background operations on,
  15. which can corrupt files.
  16.  
  17. Extensive bug hunt story following, which might help Acorn in killing this
  18. bug before it kills them (I guess schools will go apeshit over this, as
  19. it causes pure data loss !).
  20.  
  21. While copying a few graphics files from Archimedes to my MSDOS box, this
  22. incredibly obscure and potentially very dangerous bug manifested itself.
  23. My zippy hardware PC link not being available due to it being taken out
  24. for other hardware development I resorted to using a floppy to transfer
  25. the files.
  26.  
  27. The resulting JPEG files, after copy from Arc to floppy and then from floppy
  28. to PC, were all correct, except two, which showed a strange 'Premature EOF'
  29. error. Checking the lengths on both sides confirmed they were exactly equal
  30. size. Then *DUMPing revealed that the last few bytes of the resulting DOS
  31. files were definately corrupted.
  32.  
  33. Repeating the copy, and, prior to porting over the floppy, copying the file
  34. off the DOS floppy again on the Arc (i.e. on, and off again), revealed ...
  35. no errors ! Weird. *Then* putting the floppy in the DOS machine and copying
  36. the file revealed ... no errors ! Being used to these 'can't happen' bugs,
  37. I managed to remain calm and think a bit. Then, being curious, I repeated
  38. the 'on Arc to floppy, eject, insert in DOS, copy' procedure, which
  39. revealed ... no errors ! Wow, now I really must be slipping, thinketh I.
  40.  
  41. But, getting a vague suspicion (having written file buffer handling
  42. routines for several of my apps), I repeat this with a different length
  43. file. Yep. Corrupted. The why is now immediately apparent : as was my
  44. suspicion, the mysterious 'ok again' file was not really ok, it just
  45. happened to look that way on disc, because it happened to be written
  46. over a correct copy. It must have been the last part missing the first
  47. time.
  48.  
  49. Another test proved this. But why only these two ? Obviously something to
  50. do with filelength. So I started testing and watching the background copy
  51. counters. After a large number of tries, it seems that small files with
  52. length mod 4096 <= 256 are consistently being corrupted, and not when >256.
  53. This does not explain my &1FCEC file consistently being corrupted, but
  54. watching the progress counters reveals that for long files the counter
  55. appears to decrement by varying block sizes. Nevertheless, at least every
  56. time the last block shows 256 bytes or less, the corruption occurs.
  57.  
  58. Corruption in these cases extends, as far as I can see, to the last 256
  59. byte block. This is *not* written to disc and contains old garbage.
  60.  
  61. Further experimentation with rereading on Arc before porting the floppy,
  62. and doing *Dismounts at different times, reveals that both seem to cause
  63. the missing small data chunk (obviously still buffered by the FS) to be
  64. written to the disc, while removing the disc (waiting till light off)
  65. without doing either consistently corrupts these special length files.
  66. Fully resetting the machine before doing either also shows the corruption
  67. on re-reading the files on the Arc. Definately something wrong in the
  68. 'clean up' or 'update file to media' department.
  69.  
  70. Having seen the match between the 'to go' bytes counter and the corrupted
  71. part, I then tried non-multitasking copy. This works all the time and does
  72. not corrupt the files.
  73.  
  74. Experimentation with ADFS discs reveals that ADFS (thank God !) does *not*
  75. suffer from data corruption in the same special cases. Must be DOSFS.
  76.  
  77. E.g. what we have here is certain corruption that occurs when writing files
  78. with a specific length to DOS floppy (possibly with a specific configuration
  79. resulting in specific buffer sizes etc., I don't know, Acorn does), and
  80. *not* dismounting or re-accessing the floppy (which is usual, hands up
  81. everybody who always dismounts each and every floppy before removal), and
  82. then removing it to be read on another machine.
  83.  
  84. Over to you, Acorn. What's your excuse ? This is bloody dangerous !
  85.  
  86.  
  87. John Kortink
  88.  
  89. Student of Informatics at the University of Twente, The Netherlands
  90. (God, will I ever stop doing things 'on the side' and get it done?)
  91. NETMAIL : kortink@cs.utwente.nl              DISCLAIMER : the usual
  92.