Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!yoda.eecs.wsu.edu!rnelson
From: rnelson@eecs.wsu.edu (Roger Nelson - Grad Student)
Newsgroups: comp.sys.amiga.tech
Subject: Re: HD validation error (possible cause?)
Message-ID: <1991Jan16.040022.22135@eecs.wsu.edu>
Date: 16 Jan 91 04:00:22 GMT
Reply-To: rnelson@yoda.UUCP (Roger Nelson - Grad Student)
Organization: Washington State University, Pullman
Lines: 59

------

>	Are you certain lharc doesn't conflict with itself?  

I ask then, at what level does lharc "conflict with itself". 
In what way could lharc "conflict with itself".

Apparently there is some conflict with some resource, Since lharc has
never crashed while running multiple lharc process to the ram disk, I
would have to conclude that the resource in question is the HD.

Is it not the responsibility of the File System to manage the HD resource?
If the File System is reliable against large numbers of simultaneous
operations, then there must be some flaw in the HD, the controller, or the
HD driver software?

Since it appears that others have had problems with multitasking lharc and
other utilities on HDs, we can probably (although not necessarily) rule out 
the HD itself and probably the controller as well.  This would leave the
device driver or bring us back to the file system.

> A number of ported utilities are known to assume that only one copy of their 
> program is running (or running in a given directory).  

Why shouldn't a program assume it is the only copy of itself running?
Why should this be any different than running several different programs?
Why should this cause problems? and why only with the HD.  What could
lharc be doing to cause the machine to crash in this manner?

By "running in a given directory" does this mean writing to a given
directory?  I assume that lharc is crashing during some sort of write
operation, since it would seem unlikely that there is a problem with
reads (I usually unarc from the HD to MEM).

Given the nature of what lharc does, I don't see that it would be doing
anything more complex opening a file and writing to it a character at
a time (or, most likely, a buffer at a time). Surely the Amiga can handle 
multiple process do that kind of operation.  It apparently can since I haven't
experience this problem with zoo.

I suppose I can resign myself to the idea that the problem rests totally
with lharc, but this leaves the question: what is lharc is doing
that should be avoided?  

The answer should be nothing if lharc is making standard system calls
correctly.

Has anyone experienced lharc crashing the machine whilst multiple lharc
processes are unarchiving to devices other that the HD or to other
file systems?

_____________________________________________________________________
      ______________
____  | ^          |    Roger Nelson          rnelson@yoda.eecs.wsu.edu
\^^ |*| ^          |    Agricultural Engineering Department     ///
 |^^//  ^^         |    Computer Science Department            ///
 |  '  ^          +|    Washington State University        \\\///
 \_  ^    _________|    Pullman, WA 99164                   \XX/
   `-----'