From:	Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id:	<200008161238.OAA09506@lws256.lu.erisoft.se>
Subject:	Re: Patch: open() adjustment for symlinks
To:	djgpp-workers AT delorie DOT com
Date:	Wed, 16 Aug 2000 14:38:13 +0200 (MET DST)
In-Reply-To:	<399A8760.7F5943F3@softhome.net> from "Laurynas Biveinis" at Aug 16, 2000 02:21:52 PM
X-Mailer:	ELM [version 2.5 PL3]
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > 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:

As a matter of fact I _can_ envision a possible use for a symlink
FSEXT hook: suppose someone want to be able to handle umsdos
extensions on FAT?


Right,

						MartinS

- Raw text -