[comp.unix.xenix] 'huge directory' error

kmcvay@onebdos.UUCP (Ken Mcvay) (05/08/90)

 Allow me to quote your posting of 05 May 90

 DS> From: dennisDennis S. Breckenridgeebulus.UUCP (Dennis S. Breckenridge)
 [stuff deleted]
 DS> Here is my suggestion:
 DS>
 DS> mkdir /usr/spool/temp
 [balance of solution deleted]
 DS> #Presto Chango! its fixed.

 Fixed, as advertised. Reminds me of the early days in FidoNet, when we
 didn't have any optimizers, and had to manage the same routine every day to
 shrink the netmail message directory....which leads one to wonder if indeed
 there's an easier way to do things - are there optimizers out there than can
 be run from cron, that will solve problems like the "huge directory" error?

 DS> in direct blocks like this output from fsdb. If you are going to play
 DS> with this command BE CAREFUL! It will eat a file system with a typo!
 DS>
 DS> >>>/dev/rdsk/0s1(root): 1K byte Block File System
  [Encrypted Greek deleted]

 DS> INDIRECT Block2 points to a list of 256 pointers to 256 pointers
 DS> to 256 pointers to more blocks.

 right. (are you any relation to my mother-in-law?)

 DS> Your error is reported when all DIRECT blocks are used up and unix had
 DS> to use INDIRECT BLOCK1 for a directory file. Clear as mud eh!

 In spite of my inability to decrypt your graphic explanation, the last two
 lines *did* settle into the gray matter and explain the reason the error
 message appeared....but they didn't explain how it got there in the first
 place...i.e. I know what caused it (see below) but not why Xenix couldn't
 make it right after the cause was rectified...

 Cause: bnews dumped .ina* and .ara* files into the directory prior to
 filtering them through to the akcs message system. In playing with SGID'ing
 the filtering utilities, I forget to change the group on the binaries, and
 the temporary messages couldn't be filtered. So they just sat there - about
 8000 of them - until I deleted them. That's what caused the problem.

 Question: Why didn't Xenix FIX the problem while it was obeying the commands
 which deleted the 8000 files in the first place?


  |Ken McVay   ~  1B Systems Management Limited, Nanaimo, British Columbia|
  |UUCP: uunet!van-bc!oneb!kmcvay                    InterNet: kmcvay@oneb|
  |Voice: 604-758-7414  DOS: 604-758-2928 (HST)  XENIX: 604-758-8162 (PEP)|


--  
Ken Mcvay - via IMEx node 89:681/1
uunet!van-bc!oneb!onebdos!!kmcvay
kmcvay@onebdos.UUCP