home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / acorn / 9443 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!warwick!dcs.warwick.ac.uk!thughes
  2. From: thughes@dcs.warwick.ac.uk (Tom Hughes)
  3. Newsgroups: comp.sys.acorn
  4. Subject: Re: Bug alert : RO3.1 corrupts DOS files
  5. Message-ID: <1992Nov9.102048.24186@dcs.warwick.ac.uk>
  6. Date: 9 Nov 92 10:20:48 GMT
  7. References: <1992Nov9.002405.5422@cs.utwente.nl>
  8. Sender: news@dcs.warwick.ac.uk (Network News)
  9. Organization: Department of Computer Science, Warwick University, England
  10. Lines: 49
  11. Nntp-Posting-Host: stone
  12.  
  13. In article <1992Nov9.002405.5422@cs.utwente.nl> kortink@cs.utwente.nl (John Kortink) writes:
  14. >Serious RISCOS 3.1 bug alert !
  15. >
  16. >This concerns copying files to DOS floppies with background operations on,
  17. >which can corrupt files.
  18.  
  19. [...story of bug hunt deleted...]
  20.  
  21. >Further experimentation with rereading on Arc before porting the floppy,
  22. >and doing *Dismounts at different times, reveals that both seem to cause
  23. >the missing small data chunk (obviously still buffered by the FS) to be
  24. >written to the disc, while removing the disc (waiting till light off)
  25. >without doing either consistently corrupts these special length files.
  26.  
  27. I'm fairly sure that this is well known, as I read somewher recently
  28. (in Archive I think) that you should *always* dismount a DOS floppy
  29. before ejecting it, as not doing so means that the write behind buffer
  30. will not be flushed to disc, so the last sector or so written to disc
  31. will not actually have been written.
  32.  
  33. >Fully resetting the machine before doing either also shows the corruption
  34. >on re-reading the files on the Arc. Definately something wrong in the
  35. >'clean up' or 'update file to media' department.
  36.  
  37. I'm not sure if it is due to a bug in DOSFS which doesn't flush the
  38. buffer when it finishes an operation, or whether it was the intended
  39. mode of operation.
  40.  
  41. >Experimentation with ADFS discs reveals that ADFS (thank God !) does *not*
  42. >suffer from data corruption in the same special cases. Must be DOSFS.
  43.  
  44. I am pretty sure that ADFS is safe - it's only DOSFS that suffers.
  45.  
  46. >Over to you, Acorn. What's your excuse ? This is bloody dangerous !
  47.  
  48. Whether this is a bug or the way things were supposed to work, it is
  49. *very* bad. If this was in the specification, I worry about the person
  50. who wrote the spec... Please, please, please sort it out Acorn.
  51.  
  52. Tom.
  53.  
  54. ============================================================================
  55. Tom Hughes, CS3
  56.  
  57. thughes@uk.ac.warwick.dcs            57 Shakleton Road
  58. csugk@uk.ac.warwick.csv              Earlsdon
  59.                                      Coventry
  60. (0203) 673584                        CV5 6HT
  61. ============================================================================
  62.