Message-ID: <399A8760.7F5943F3@softhome.net> Date: Wed, 16 Aug 2000 14:21:52 +0200 From: Laurynas Biveinis X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii 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> <399A6110 DOT CA193440 AT softhome DOT net> <7263-Wed16Aug2000150127+0300-eliz AT is DOT elta DOT co DOT il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > Sorry for being unclear. Let me try to explain. Thanks. > If `__solve_symlinks' boils down to `_open' and `_read', which *can* > be hooked by an FSEXT, then perhaps there's no problem. Yes. > We need at > least document the fact that FSEXT cannot hook the symlink resolution > (thus, an FSEXT cannot easily simulate symlinks), but that the FSEXT > will see the symlink-related calls via `_open' and `_read' handlers. What about this draft? Index: fsext.txh =================================================================== RCS file: /cvs/djgpp/djgpp/src/libc/fsext/fsext.txh,v retrieving revision 1.7 diff -u -r1.7 fsext.txh --- fsext.txh 2000/06/19 18:00:56 1.7 +++ fsext.txh 2000/08/16 12:24:43 @@ -10,6 +10,12 @@ gain control when one of these low-level functions is called on a file descriptor set up by the extension. +Note that @code{__solve_symlinks} does not contain FSEXT handler, so +an extension cannot intercept symlink resolution directly. However, +@code{__solve_symlinks} eventually calls @code{_open} and @code{_read}, +so if you provide open and read handlers, your extension should work OK +with symlinks too. + Each extension must provide one or two handler functions. All handler functions take the same arguments: