Mail Archives: djgpp-workers/2001/05/20/14:59:10
> Date: Sun, 20 May 2001 18:36:35 +0100
> From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> [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?
The code you saw in Fileutils 4.0 is working in Tar with no problems I
know about. It allows to create on DOS/Windows tar archives which
state arbitrary user/group ownership.
> > > 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?
Yes, I meant libc functions getpwnam and friends.
The library functions (getpwnam etc.) return a failure indication if
the user/group they see is not the one they know about. In effect,
they behave as a Unix system with only one known user and only one
known group: the current ones. If the programs which actually use
those library functions need to work around that behavior, it probably
means that it (the behavior) is not very useful.
- Raw text -