Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3B0800A3.5D645963@phekda.freeserve.co.uk>
Date:	Sun, 20 May 2001 18:36:35 +0100
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: ANNOUNCE: Fileutils 4.0 beta 2
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010520172522 DOT 23429A-100000 AT is>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> On Sun, 20 May 2001, Richard Dawe wrote:
> 
> > I don't like the idea a function of setting the user and group and not
> > restoring them, just so the C library "thinks" that we are the
> > specified user & group. I think the user and group switch should be
> > local to the function.
[snip]
> In theory, yes.  But userspec.c is not a library function, it is only
> used by certain programs, and those programs do their thing and then
> exit.

But it's in the shared code / platform support code in lib/ - surely that
counts as a library? I agree that Fileutils use of these files is
short-lived, but what about tar? If you don't think it'll be a problem,
then I'll stop being so idealistic. 8)

> > It's not the values that matter. What matters is that you can
> > distinguish between the "owned by me" and "not owned by me" and "in my
> > group" and "not in my group" cases.
> 
> But in DJGPP, all files are "owned by me".  (They all are also "owned by
> you", for that matter.)  So we cannot distinguish between these two
> kinds anyway.

OK, but for the purposes of chown, chgrp, etc. we need to distinguish
between "me" and "not me". Currently it's done using some hackery, but it
could be done much more cleanly if getpwnam(), etc. had a concept of "not
me" in addition to "me".

> > I think this is a better way to go. But how would we do it? We could
> > add functions to create other users & groups on the fly, e.g.:
> >
> >     __add_user("brian", 123);
> >     __add_group("root", 0);
> 
> Actually, I thought about changing getpwnam etc. so that it would not
> reject users other than specified by $USER.  If so many programs which
> use getpwnam and friends need to work around this, it's a sign that the
> behavior is not useful.

I'm a bit confused - which behaviour would not be useful? Is the current
behaviour not useful, because of necessary workarounds? Or would your
proposed behaviour not be useful, because it might need workarounds?

Bye, Rich =]

-- 
Richard Dawe
http://www.phekda.freeserve.co.uk/richdawe/

- Raw text -