Final Word on the Password Problem

[Kenneth Brody]

"Jay R. Ashworth" wrote:
[...]
> > > > > > However, it you change the password such
> > > > > > that the processing table's password no longer matches the
> > > > > > site password, then filePro will start asking for the password
> > > > > > before you can see/edit the processing.
[...]
> > _Which_ "*which* password" are you referring? There's the password in
> > the processing table, the site password in the original machine, and
> > the site password on the new machine. I also mentioned changing the
> > site password, as well as passwords matching or not.
> 
> I'm referring to "the password which filePro will start asking for".

Since we are referring to "before you can see/edit the processing",
I am obviously referring to the processing's password.  (What other
password would filePro want at that point?)

[...]
> > If the password stored in the table does not match the current site
> > password, then you need to know the password in the processing table
> > in order to view it. (No password is needed to run it.)
> 
> "...using dcabe."

... or dclerk or dreport.

>  Obviously if it's in ASCII, you don't need to know
> that password to edit it in vi.

Correct.

> So, Nancy's advice, which *sounds like* "run right out and set site
> passwords on all your machines right now" to *me* is indeed bad,
> because it won't protect most of those files until they're touched by
> dcabe, which could take forever.

In this case, we're talking about "protecting" them from getting a password
that you don't know, so Nancy's advice still holds here.

> It's really only useful advice for developers on development machines
> freshly installed, with no work done on them yet, as far as I can see.
> Am I missing something?

Let's get back to the OP's problem.  They had a system which probably
didn't have a site password.  At some point, someone set a site password,
and new/modified processing tables started to get that password which was
unknown to the OP.  Sometime later, someone, somehow, changed the site
password to something else.  (Perhaps they moved to a different machine?)
At that point, all of those processing tables that were created/modified
in the interim had a password unknown to the OP, and were inaccessible.

Nancy's position, as I understand it, is that had the machine(s) all had
a known site password, this unknown password should never had snuck into
these processing tables.

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody at spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+