Mail Archives: djgpp-workers/2000/08/15/17:21:01
> Date: Tue, 15 Aug 2000 22:00:47 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> > @findex open AT r{, accepts @code{O_NOLINK} and @code{O_NOFOLLOW} flags}
>
> Will change that. Also, it could be cool if this entry says that open()
> supports symlinks now... Maybe the following will do there?
>
> @findex open AT r{, accepts @code{O_NOLINK} and @code{O_NOFOLLOW} flags}
> @findex open AT r{, supports symlinks}
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}}
> > Bother. __solve_symlinks doesn't have an FSEXT, does it?
>
> No, it doesn't right now. I can't think of any reasonable reason
> why user should intercept symlink resolving, any ideas there?
I'm not sure we need this, either. 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'.
Perhaps the fact that __solve_symlinks calls _open and _read, which an
FSEXT can catch, is indeed enough. 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'.
- Raw text -