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 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/