Mail Archives: djgpp-workers/2000/08/16/08:25:35
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:
- Raw text -