home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.acorn.tech
- Path: sparky!uunet!pipex!warwick!sunserver1.aston.ac.uk!uhura!davism
- From: davism@uhura.aston.ac.uk (Mik Davis)
- Subject: Re: ADFS maps
- Message-ID: <1992Nov9.113440.11646@aston.ac.uk>
- Sender: usenet@aston.ac.uk (Usenet administrator)
- Nntp-Posting-Host: uhura
- Organization: Aston University
- References: <1dlg13INNs5b@oak6.doc.ic.ac.uk>
- Date: Mon, 9 Nov 1992 11:34:40 GMT
- Lines: 71
-
- 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 | | |. |_/ |_| \/ |/_'
-