samba - Oct 1997 - is this a bug

Hi all,
can somebody tell me if this is a bug or a feature? I'm using samba
1.9.17p2.
Using security=share, all works as expected.
Using security=user (which I'd prefer) AND revalidate=yes, I cannot mount 
my homedir share (or any passwd protected share) at all. 
I get "SMBtconX failed. ERRSRV - ERRbadpw."
Since I use the same password to browse (smbclient -L SERVER), and I get the
browse list, I don't think the passwd is wrong, nor that it should be all 
uppercase.
Without revalidation, it works (I can access shares).

Am I doing something wrong? Is revalidate mutually exclusive WRT security=user
(I read many docs, and didn't find any clue about this)?

Anyway, thanks to all the samba team. 1.9.17p2 is really good work! Sorry it
this question is silly.
-- 
||    || |||||||  Marco Frattola                     Microsoft is not the answer
||`..'|| |||...   Piacenza, Italy                    Microsoft is the
question
|||  ||| |||''    mfrattola@mail.enjoy.it            "No" is
the answer
|||  ||| |||      www.enjoy.it/users/~mk/index.html  Live Linux, live free!

At 03:19 15/10/97 +1000, mfrattola@mail.enjoy.it wrote:
>Am I doing something wrong? Is revalidate mutually exclusive WRT
security=user
>(I read many docs, and didn't find any clue about this)?
Dear Marco,
I can confirm that this is indeed the case. I wrote a message to the list in
October '96, in which I also suggested some additions to the documentation,
that unfortunately didn't get included.
For your convenience, I copy here an excerpt of my former message.

ciao
        Fulvio
>Dear Samba List,
>
>I've just finished debugging a problem with user level security, so I
let you
>all know. This is for 1.16p2, but I think it's common to most Samba
versions.
>
>The "problem": user level security does NOT work if you have
revalidate=true
>in your smb.conf
>
>The reason: in user level security, the password is never send, except in
the
>initial session setup. Revalidate=true prevents samba from re-using the
>session setup password in tree connect commands, so no service can ever be
>connected, except public ones.
>
>The solution: It seems to me that this is a "correct" behavior (at
least a
>very consistent one), I had trouble because it isn't documented
anywhere. And,
>since I had a server with revalidate=true running in share level since
years,
>when I switched to user level it took me a while to figure it out.
>
>I propose to add the following information into DIAGNOSIS.txt, in TEST 7:
>
>If it says "bad password" then the likely causes are:
>...all the current cases...
>- you are running in user level security with revalidate=True
>
>And maybe update the "revalidate" entry in the smb.conf man page
to read:
>
>     If "revalidate" is True  then  the  client  will  be  denied
>     automatic access as the same username. Note that this will not
>     work if the client is is user level security.
     ,==================================,=================================,
    /  Fulvio Corno <corno@polito.it>  /  Dip. Automatica e Informatica  /
   /  Tel: +39 11 564.7053            /  Politecnico di Torino          /
  /  Fax: +39 11 564.7099            /  C.so Duca degli Abruzzi 24     /
 /  http://www.polito.it/~corno     /  I-10129 TORINO (Italy)         /
'============= CAD group: http://www_cad.polito.it =================='