🚀 go-pugleaf

In article <memo.895245@cix.compulink.co.uk>, amclintock@cix.compulink.co.uk ("Cray Communications, Alex McL") writes:
|> In-Reply-To: <727580969snz@cryton.demon.co.uk> altman@cryton.demon.co.uk (Hugo Fiennes)
|> 
|> Hard Disk Whinge
|> I don't like my IDE drive/controller
|> which I bought from ICS.
|> 
|> 1) 25second boot up time (with RiscOs2)
So optimise your boot sequence...  What are you doing during bootup?  My
system takes far longer than that to spring into life.  Or are you talking
about spin up time?  In which case 25 seconds is probably about par for the
course...


|> 2) window bugs in filer, paths longer
|>    than 40 chars (or so) cause windows larger
|>    than they need to be. (big gaps to the right)
|>    Or perhaps this is a riscos bug.
Well this is a feature of the window manager.  The minimum width of any
window is the width it's title bar had when it was created.  Subsequent
changes to the title text make no difference.   This feature is present in paint
too, and every program I've written.  It's not HCS's fault.  Don't know how
to get around it apart from creating the window with a very small title, and
then changing the title afterwards.
Come to think of it, I'm pretty sure the filer DOES do this - you can shrink
the windows, it's just their default size which is large enough to see the
full filename.


|> 3) The occasional bad drive error.
|> 
Can't help you on that.  Might be your own programs or others with hard
wired drive numbers in.  (Illegal but it happens.)  Particularly easy to
get this happening with expansion of system variables - you might have
something hardwired to a floppy drive number causing this error.  Again don't
leap down HCS's throat.

|> I still haven't got a satisfactory answer to these
|> questions. I suppose I can't really complain
|> though since I have had it for three months+
Well who have you asked before now?


|> Does anyone know why the "*map" command
|> fills my screen with bits of free space.
|> Shouldn't it all be in one continuous block?
|> *compact reduces it a bit...
Yes it should do.  The E-type format maintains a pattern of lots of smaller
blocks near the middle of the disk (logically speaking, so I mean the tracks
half way along as opposed to the hub) and larger blocks out towards the edge,
so small files like Obey ones which need to be accessed fast for slick
directory opening can be found with the minimum seek distance, and large ones
which are going to take a while to load anyway get stuck in the less
desirable areas of hard disk real estate.
So don't complain, this is a Filecore feature anyway...


Ian Griffiths