bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: user.c, user.h


From: Andrey Aristarkhov
Subject: RE: user.c, user.h
Date: Wed, 14 Aug 2002 16:44:16 +0400

> -----Original Message-----
> From: Derek Robert Price [mailto:derek@ximbiot.com]
> Sent: Wednesday, August 14, 2002 4:25 PM
> To: Andrey Aristarkhov
> Cc: bug-cvs@gnu.org
> Subject: Re: user.c, user.h

> >>look messy and don't necessarily remain portable across OSs, but I'm
> >>hardly going to require that for acceptance of this patch.
> >>
> >>
> >I agree with you. I can write the function in root.c.
> >
> >
> 
> If you like.  Maybe turn it into a separate patch.  Like I said, I
won't
> require it for your first patch.
Ok. Let's change it later.

> 
> >My suggestion is place get_password(char * username, char *
> >passpwd_file) as a common function and reuse it in user.c, login.c
and
> >server.c, since it has the same logic for .cvspass and
CVSROOT/passwd.
> >Function get_alias also could be placed in server.c and reused.
> >
> >
> 
> I still think it should be modeled more after the getpwnam() type
system
> passwd functions and return a pointer to a structure containing all
the
> fields from the file so that the data can be cached and the passwd
file
> won't need to be reaccessed for every field.
You are right. There must be a struct like this 
struct cvs_passwd {
        char * username;
        char * passwd;
        char * alias;
        /* from CVSROOT/users */
        char * notify_name;
} cvspasswd_t;
and corresponded function 

cvspasswd_t * getcvspwent(const char * user, const char * passwd_file);
or even better 
cvspasswd_t * getcvspwent(const char * user, int file_type /*
PASSWD_LOCAL | PASSWD_ROOT */);
PASSWD_LOCAL is for ~/.cvspasswd and PASSWD_ROOT is for CVSROOT/passwd

> >I think user.h is more suitable place.
> >
> 
> Ok.
Done.

> >I try to explain why I have done it in this way. User can work with
> >repository in local and server mode. In a server mode there is no
> >problem to detect current user name, but it's not possible in local
mode
> >- only the caller principal can be detected.
> >
> >
> 
> Unless my grasp of NT terminology is worse than I think, under local
> mode on UNIX, the caller principal is assumed to be the user name.
Does
> something prevent that under NT?
Sorry for some uncertainty. I meant that user's caller prinicipal and
CVS user name could be deferent. 

Regards,
Andrey





reply via email to

[Prev in Thread] Current Thread [Next in Thread]