Mail Archives: djgpp-workers/1999/03/09/05:14:50
On Mon, 8 Mar 1999, Mark E. wrote:
> > I don't see such interpretation in the Unix man pages. Relative file
> > names are allowed and are interpreted as usual: relative to cwd.
> >
> > > + if (unix_emu)
> > > + {
> > > + /* If a root directory already exists, the new root directory
> > > + must be relative to the existing root directory.
> > > + If not, then reject the path. */
> > > + if (__djgpp_root_len > 0 && *buf != '/')
> > > + {
> > > + errno = EACCES;
> > > + return -1;
> > > + }
> >
> > Nate tried on Linux and said that the argument passed to `chroot' is
> > always interpreted as relative to the current root. However, your
> > implementation calls `_fixpath' too early, and thus deviates from this
> > behavior.
>
> First you say arguments that are relative filenames are relative to
> the cwd, then you say all arguments are relative to the current root.
> Which is it?
Both ;-)
Sorry, I was unclear in the last statement. The argument is
interpreted relative to the current root, IF IT BEGINS WITH A SLASH.
The second statement above referred only to such names, but I should
have told that explicitly.
> > For example, if the current root is "c:/foo" and `chroot' is called
> > with "/foo/bar/baz", then `chroot' will allow it (I think; I didn't
> > actually try this) because it generates "c:/foo/bar/baz" and then
> > removes "c:/foo" from it.
>
> That's not quite how it works.
Okay, then I'm sorry I've brought up a non-issue.
> Substituting stricmp for strnicmp is not a good option, at least not
> without some hackish code to temporarily stick in a '\0' in the
> string I'm checking, do the comparison, and then restore the
> character.
Well, actually, that's what I had in mind ;-). Of course, there are
half a dozen other possible solutions, it's for you to choose.
- Raw text -