Xref: utzoo comp.sys.amiga:75717 comp.sys.amiga.tech:17415
Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!thad
From: thad@cup.portal.com (Thad P Floryan)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: HD Errors
Message-ID: <37524@cup.portal.com>
Date: 3 Jan 91 15:58:01 GMT
References: <cbUFsB200VIFFNxVlN@andrew.cmu.edu> <37492@cup.portal.com>
  <1991Jan2.190655.15790@jato.jpl.nasa.gov>
Organization: The Portal System (TM)
Lines: 89

jdickson@jato.jpl.nasa.gov (Jeff Dickson)
in <1991Jan2.190655.15790@jato.jpl.nasa.gov> writes:

	I made the mistake one time of rebooting the machine while a berserk
	program wrote non-stop to a file on my hard drive. I had to reformat.
	But then a disk can be corrupted by doing this on most any system. 

Perhaps.  But I've never had that problem with UNIX.  Absolute worst case was
when *I* screwed something up badly while testing, so just reached around and
hit the reset button, and in 5 minutes the system was back up fine, bad files
were repaired, and I continued (literally) as if nothing had happened; having
process memory protection (e.g. an MMU) with UNIX also helps!

If you want some advice, NEVER, EVER test a "new" program to/from/on a HD.
Always use RAM: (or whatever else you find suitable).

	It'd be nice if C= would include some fsck program, but that they
	haven't isn't going to deter my interest from programming the Amiga.
	The meek possibility of this happening stresses the importance of
	backups.

No question about backups!  :-)   Attached is something I posted to another
newgroup last year that you may find interesting/amusing.

As for my comment re: "my stopping commercial development", that was mostly a
marketing decision due to the nature of most the software I write (4GL DBMS
products, language compilers, and products based on computational linguistics
and natural language processing by automata) simply being priced out of what
is presently perceived as "the Amiga marketplace."  We (my company) are making
the switch to UNIX and when SVR4 becomes available on an Amiga platform we'll
(probably again) embrace the Amiga.  At present my products are on what are
termed "mainframes" and "super minis."

I personally still write a LOT of stuff for ol' Ami, and there's even some of
my stuff floating around on Fish Disks, archive sites, and elsewhere.

I still feel "strongly" about the fragility of the Amiga filesystem.  Just
reading the Usenet newsgroups, an inordinate disproportionate share of HD
errors (requiring reformatting and reloading) seem to plague ONLY the Amiga.
Of the thousand or so comp.sys.amiga.* articles still unexpired here, I can
probably find well over a hundred lamenting serious HD problems.  Contrast
that scenario with my attachment (below).

Thad

Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]

-------------------- begin attachment

Seems that with all the other issues and activities recently, I neglected to
post a followup to my query "Ascertaining a file name given a HD block
number."

The solution is actually quite straightforward:

	Brant Cheikes' program ``bf'' (block find, version 1.3, available at
	the osu-cis archive site) returns the inode(s) of files given the
	physical block number, and

	either "ncheck" or "find -inum # -print" will return the filepath/name
	given the inode number.

In my recent situation I again "lucked out" since the block I spared belonged
to an *.o file, so "nothing" was lost.

During the past several years I've only had two blocks "go bad" amongst some 8
systems and have never lost anything.

Which brings me to my favorite exhortations (as many have heard before at
various users' groups meetings here in Silicon Valley) and transcribed from
recordings made at some of the meetings:

``	Hard drives WILL fail; the only uncertainty is when, but it is
	guaranteed they WILL fail.

	All things mechanical, be they switches, connectors, sockets, cables,
	or rotating memories, will wear out or self-destruct at the most
	inopportune time in accordance with Murphy's Law and its corollaries.

	Your only defense is to develop a system backup regimen and abide it.
	The one day you neglect your {sysadmin | operator} duty is the day
	your most-valued data develops software rot and bit decay.	

	And let us not also forget the most dangerous command on the {insert
	favorite system name here} is the carriage return; examine what you
	have entered BEFORE flailing away at the RETURN key as most commands
	are NOT retractable.
	...
''