Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!mailrus!cornell!uw-beaver!zephyr.ens.tek.com!tektronix!sequent!cseaman
From: cseaman@sequent.UUCP (Chris "I'm Outta Here, Man!" Seaman)
Newsgroups: comp.sys.amiga
Subject: Re: The A-590/2091 FFS problem
Summary: Nope.  Doesn't fix anything.
Keywords: Location 0
Message-ID: <38440@sequent.UUCP>
Date: 11 Jul 90 20:49:35 GMT
References: <2085@gould.doc.ic.ac.uk> <6600012@okcusr.UUCP> <1449@nyx.UUCP>
Organization: Sequent Computer Systems, Beaverton, OR
Lines: 59

bscott@nyx.UUCP (Ben Scott) writes:
< bn@okcusr.UUCP writes:
< >I am also having this problem with my brand new A590. I found that VirusX3.2
< >works like a charm, but 4.0 crashes when it's trying to set up. Another 
< >problem that I'm having is that ever since I installed the HD, some of my
< >file requesters contain the string "gdos" as though the DOS already selected
< [...]
< >because the term assumes I want to upload a file called "gdos". Does
< >anybody know a cure for this??? By the way, the problem mentioned in the
< 
< This keeps popping up so I'm posting publicly (perhaps this is a candidate for
< the Intro to c.s.a. file?) - also due to some problems I can't reliably post
< mail replies on comp.sys.amiga... anyhow:
<
< There's a simple, clean fix for this.  Go in through HD_Toolbox, to "Partition
< Drive", then click on "Advanced Options" and you'll see a box labeled "Add/
< Update Filesystems" - click this and then change the version number of the FFS
< from 0 to 1.  

Sorry, but this doesn't fix anything.  I have had this problem since the
day I installed my 2091, and NONE of the suggested fixes have done anything.
I have a 2091 with a Quantum 105MB drive (purchased SEPARATELY).  The drive
did not come with ANY filesystem installed on the RDB.  The version which
came on the 2091 Installation disk matches the 'correct' version in every
respect (the size, the embedded version string, the timestamp on the file,
etc).  This has been verified by someone at Commodore (though I've forgotten
who).  Suffice it to say that I am still forced to manually poke a 0L into
address 0 on every reboot, or MANY programs fail miserably.

< Version 0 as shipped is a debugging version of some kind, which puts a pointer
< to someplace in memory which has the string "gdos" in it - (not sure what but
< it's probably a memory resident library someplace) - buggy programs which have
< uninitialized pointers or which expect a null to be in location zero will find
< what appears to be a null-terminated string pointed to by the number at 0.
< This will cause annoyances and sometimes crashes depending on the program.
< Note also that this is a kind of bug, but it only affects other buggy programs.
< Location zero is not to be played with or counted on to have zero in it.
< 
< It was an oversight to ship version 0 enabled instead of version 1, so you can't
< really call it a bug.  Once you make the switch all problems will go away.
< 
< .                           <<<<Infinite K>>>>

Believe me, I REALLY wish this was the case.  Unfortunately, it isn't.  In fact,
the version of FFS that I use with the 2091 is IDENTICAL to the version I
used on my 2090a, which never caused any problems.  Whatever the problem is,
it is not in the filesystem.

If anyone has any other ideas, I am willing to try anything.  However, I
have tried the 'change the version to 1', 'manually force the filesystem
to be updated', 'install the filesystem from another Workbench disk' tricks
more times than I care to mention.  So please, DON'T suggest I do these
things again.  THEY DON'T FIX THE PROBLEM!

-- 
Chris (Insert phrase here) Seaman |    /--\
cseaman@sequent <or>              |   |    |         "This is as real as
...!uunet!sequent!cseaman         |   |  \ |      your so-called 'Life' gets"
The Home of the Killer Smiley     |    \--X__