home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / acorn / tech / 539 < prev    next >
Encoding:
Text File  |  1992-11-09  |  3.8 KB  |  84 lines

  1. Newsgroups: comp.sys.acorn.tech
  2. Path: sparky!uunet!pipex!warwick!sunserver1.aston.ac.uk!uhura!davism
  3. From: davism@uhura.aston.ac.uk (Mik Davis)
  4. Subject: Re: ADFS maps
  5. Message-ID: <1992Nov9.113440.11646@aston.ac.uk>
  6. Sender: usenet@aston.ac.uk (Usenet administrator)
  7. Nntp-Posting-Host: uhura
  8. Organization: Aston University
  9. References: <1dlg13INNs5b@oak6.doc.ic.ac.uk>
  10. Date: Mon, 9 Nov 1992 11:34:40 GMT
  11. Lines: 71
  12.  
  13. ijp@doc.ic.ac.uk (Ian Palmer) writes:
  14. : Now I have a problem, to which I know of *a* solution to, but I don't
  15. : want it to be the *only* solution.
  16. : Over the weekend I suddenly (well over the period of a few mins) lost
  17. : 3.5Meg of my hard disc free space. I was archiving some files and what
  18. : appeared to happen is that every time a new file was placed in the
  19. : archive (producing a copy of the archive temporarily) the old one at
  20. : the end was NOT being added to the free space map (or is it taken
  21. : away?) on my IDE (A5000) hard disc.
  22. : The consequence is that I went from 3.5meg free to zilcho all for a
  23. : 500k archive. A further consequence is that *checkmap reports that the
  24. : map is inconsistent with the directory tree.
  25.  
  26.    YES YES YES!!!!  - Over the vacation, I lost 10 Mb of an A5000 IDE
  27. drives free space in *EXACTLY* this way.
  28.  
  29. : Now my question is, is there some easy way of getting that 3.5 meg
  30. : back without having to re-initialise my hard disc and reinstal all the
  31. : data?
  32.  
  33.    I couldn't think of one unfortunatly - I copied all the data from the
  34. HD to an Econet server, re-formatted the drive and copied the data back.
  35.  
  36. : What I find hard to understand is that *checkmap obviously creates
  37. : what it consideres to be the actual map of the disc during it's
  38. : directory scan in order to compare it with what is stored as the map
  39. : on the disc. So why then can it not just replace the disc map with
  40. : this correct map?
  41.  
  42.   just what I thought but no searching of manuals or disk repair programs
  43. could provide any solution other than a re-format.
  44.  
  45. : I guess there must be a reason, because in the review of the
  46. : disc recovery program in a recent Archive magazine it states that it
  47. : can't do any more than *checkmap does (or words to that effect) on the
  48. : new map discs (ie. it can't recreate the map by scanning the disc),
  49. : but I can't understand why this should be the case.
  50.  
  51.   This seems like a serious bug of some kind in the filer. It only seems to
  52. happen when archiving files and then only with ARCFS although I may be wrong
  53. about that last bit.
  54.   I also found that once the problem had occurred *every* file grabbed more
  55. free space than it should have.
  56.   The problem only occurs when the A5000 was writing to its local disk. I 
  57. seem to remember that I had to use the level-4 server software to copy the 
  58. files back in order to stop the effect happening again. Again I'm not entirely
  59. sure here (It was a couple of months back now).
  60.   The only thing I could figger out from this was that a) ARCFS caused some
  61.                                                            problem with the map.
  62.  
  63.                                                        b) The corruption in the
  64.                                                            map was such that all
  65.                                                            other apps believed
  66.                                                            that the allocation
  67.                                                            was different in some
  68.                                                            way.
  69.   
  70.   As no-one else had ever mentioned this, I assumed it was a problem with RO3.0
  71. and just urged the owner of the A5000 to get the upgrade asap.
  72.   Were you running RO3.1??
  73.  
  74. -- 
  75. ___________________________________________.
  76.  Mik Davis at Aston University, Birmingham |   .  .  __          .
  77.                                            |   |\/|  | \  _,_  _  _
  78. E-Mail: davism@uhura.aston.ac.uk           |   |  |. |_/ |_| \/ |/_'
  79.