Mail Archives: djgpp-workers/2000/08/16/08:05:10
> Date: Wed, 16 Aug 2000 11:38:24 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> > 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?
Sorry for being unclear. Let me try to explain.
I was thinking about an FSEXT which emulates a device that doesn't
exist. Calling real DOS functions on such a device will certainly
fail, since DOS doesn't know about that device.
In v2.03, calling `open' on such a device would be handled by the
FSEXT called by _open. Since now `open' calls `__solve_symlinks' as
well, I was worried that `open' will now start to fail for such
emulated devices, because it doesn't (and cannot) hook
`__solve_symlinks'.
If `__solve_symlinks' boils down to `_open' and `_read', which *can*
be hooked by an FSEXT, then perhaps there's no problem. 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.
- Raw text -