🚀 go-pugleaf

ijp@doc.ic.ac.uk (Ian Palmer) writes:
: Now I have a problem, to which I know of *a* solution to, but I don't
: want it to be the *only* solution.
: 
: Over the weekend I suddenly (well over the period of a few mins) lost
: 3.5Meg of my hard disc free space. I was archiving some files and what
: appeared to happen is that every time a new file was placed in the
: archive (producing a copy of the archive temporarily) the old one at
: the end was NOT being added to the free space map (or is it taken
: away?) on my IDE (A5000) hard disc.
: 
: The consequence is that I went from 3.5meg free to zilcho all for a
: 500k archive. A further consequence is that *checkmap reports that the
: map is inconsistent with the directory tree.

   YES YES YES!!!!  - Over the vacation, I lost 10 Mb of an A5000 IDE
drives free space in *EXACTLY* this way.

: 
: Now my question is, is there some easy way of getting that 3.5 meg
: back without having to re-initialise my hard disc and reinstal all the
: data?
: 

   I couldn't think of one unfortunatly - I copied all the data from the
HD to an Econet server, re-formatted the drive and copied the data back.

: What I find hard to understand is that *checkmap obviously creates
: what it consideres to be the actual map of the disc during it's
: directory scan in order to compare it with what is stored as the map
: on the disc. So why then can it not just replace the disc map with
: this correct map?

  just what I thought but no searching of manuals or disk repair programs
could provide any solution other than a re-format.

: 
: I guess there must be a reason, because in the review of the
: disc recovery program in a recent Archive magazine it states that it
: can't do any more than *checkmap does (or words to that effect) on the
: new map discs (ie. it can't recreate the map by scanning the disc),
: but I can't understand why this should be the case.

  This seems like a serious bug of some kind in the filer. It only seems to
happen when archiving files and then only with ARCFS although I may be wrong
about that last bit.
  I also found that once the problem had occurred *every* file grabbed more
free space than it should have.
  The problem only occurs when the A5000 was writing to its local disk. I 
seem to remember that I had to use the level-4 server software to copy the 
files back in order to stop the effect happening again. Again I'm not entirely
sure here (It was a couple of months back now).
  The only thing I could figger out from this was that a) ARCFS caused some
                                                           problem with the map.

                                                       b) The corruption in the
                                                           map was such that all
                                                           other apps believed
                                                           that the allocation
                                                           was different in some
                                                           way.
  
  As no-one else had ever mentioned this, I assumed it was a problem with RO3.0
and just urged the owner of the A5000 to get the upgrade asap.
  Were you running RO3.1??

-- 
___________________________________________.
 Mik Davis at Aston University, Birmingham |   .  .  __          .
                                           |   |\/|  | \  _,_  _  _
E-Mail: davism@uhura.aston.ac.uk           |   |  |. |_/ |_| \/ |/_'