🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.sys.amiga.tech
2 messages
2 total messages Started by Roger Nelson - Grad Student Wed, 16 Jan 1991 04:00
Re: HD validation error (possible cause?)
#8024
Author: Roger Nelson - Grad Student
Date: Wed, 16 Jan 1991 04:00
59 lines
3311 bytes
------

>	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/
   `-----'
Re: HD validation error (possible cause?)
#8026
Author: Tom Limoncelli
Date: Wed, 16 Jan 1991 17:29
22 lines
1652 bytes
In article <1991Jan16.040022.22135@eecs.wsu.edu> rnelson@eecs.wsu.edu (Roger Nelson - Grad Student) writes:

> 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?

I don't know if this is what happens with LHARC, but it is a simple
counter example to what you suggest:

The FS can only protect you to a certain (excuse the pun) extent.
What if a utility needs to create a temporary file.  It creates it as
T:lharc.tmp every time.  Running the utility multiple times will cause
problems.  This is the kind of thing I would expect from a program
ported from the PC.

I didn't like the one I found in Manx 3.6 so I wrote my own.  I
believe AmigaDOS 2.0 has a "create unique file name" system call.  
-- 
tlimonce@drew.edu     Tom Limoncelli      "Flash!  Flash!  I love you!
tlimonce@drew.bitnet  +1 201 408 5389        ...but we only have fourteen
tlimonce@drew.uucp    limonce@pilot.njin.net       hours to save the earth!"
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads