On Mon, Sep 08, 2003 at 02:15:27AM -0700, netbsd99@sudog.com wrote:
> 
> Hello Murray and David,
> 
> I have a small-ish patch here that tries to approximate what David was
> talking about. I've managed to get overnet working with it, and since
> it "seems to work" and "seems to use" the normal facilities within
> compat_util.c to do the dirty work, I thought I'd pass it on. Anyone
> feel like trying out Neverwinter nights with it? I don't have my play
> disc handy at the moment.

I don't think the version you quote handles relative paths properly.

> The extra copyout() feels a little expensive but...? I guess the real
> fix might lie within the native mkdir so we could ignore this.

Actually just fiddle with the program flow.
Maybe set 'new_name' and 'new_len' to that part of the old string
that is required (even avoiding the memcpy that kills /../), then
at the end of the function copyout or memmove the string if either
has changed from the original.

That should let you remove the trailing '/' from mkdir "fred/" while
only having one stackgap_alloc and copyout.

> Also, I don't understand what you said, David:
> 
> "if only the kernel were changed, then linux emulation
>  would fail to translate mkdir("/long_path/fred/") to
>  mkdir("/linux_root/long_path/fred/")
>  since it would kill the wrong '/'"
> 
> Could you elaborate please? Do you mean emul_find would kill the wrong
> "/" for the _CREAT switch case, or do you mean the native mkdir code
> would kill the wrong "/"? If emul_find() runs first, wouldn't
> that eliminate the possibility that native mkdir() would interfere
> with it?

I think (was a while ago) it was bcause the CHECK_ALT_FL_CREAT code removes
the last '/' of the name in a (vague) attempt to do basename() cheaply...

	David

-- 
David Laight: david@l8s.co.uk