Message-ID:	<399A6110.CA193440@softhome.net>
Date:	Wed, 16 Aug 2000 11:38:24 +0200
From:	Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer:	Mozilla 4.74 [en] (Win98; U)
X-Accept-Language:	lt,en
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: Patch: open() adjustment for symlinks
References:	<39998D7D DOT 70F85B9E AT softhome DOT net> <5137-Tue15Aug2000223737+0300-eliz AT is DOT elta DOT co DOT il> <3999A16F DOT F8809412 AT softhome DOT net> <3099-Wed16Aug2000002312+0300-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> Yes, but to avoid two index entries which begin with "open", I suggest
> to change the first one into these two:
> 
>   @findex O_NOLINK AT r{, new flag accepted by @code{open}}
>   @findex O_NOFOLLOW AT r{, new flag accepted by @code{open}}

OK, changed.

> But we do need to have some
> reasonable way for an FSEXT to survive the `open' call where it calls
> __solve_symlinks.  We don't want the `open' call to start failing for
> an FSEXT emulation just because we added symlink support to `open'.

Sorry, I don't understand: what do you mean by FSEXT surviving open call
where it calls __solve_symlinks? If you mean that __solve_symlinks()
could make FSEXT left unhandled, then I don't think it's the case:
__solve_symlinks() will call readlink() many times, eventually with
the same path, as _open() FSEXT handler would get without symlink support.

> In any case, I suggest that we
> document this somewhere, probably in the docs for `open' and maybe
> also in the docs for `__solve_symlinks'.

I will make my opinion here when I understand, what exactly needs to be documented.

Laurynas

- Raw text -