Mail Archives: djgpp-workers/2000/08/16/12:37:24
> Date: Wed, 16 Aug 2000 16:24:54 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> After some initial looking into issue, I see that FSEXT for
> readlink() would be rather exceptional: it should operate on
> file name, not descriptor, as most handlers do.
It is normal for an FSEXT to catch a name, not a handle, if the
underlying primitive identifies the file by its name. So `readlink'
is like `_open' and `stat' in this sense.
It means that readlink should use the same code as `_open' does to
call the handler, if any.
> Which leads
> me to thinking: maybe for user it's enough to provide replacement
> readlink(), which together with FSEXT hooks for open() would DTRT?
The problem is that the FSEXT doesn't hook `open', it hooks `_open'.
And `_open' doesn't know about symlinks.
The principle is that you hook the most low-level primitive which
still knows about the context enough to return meaningful results.
The question is: what is such a ``primitive'' for our symlink
emulation?
As for replacing library functions: IMHO it goes against the design of
FSEXT: it was included in the library so that application will NOT
need to replace library functions. Replacing library functions
typically means that you copy most of the library code (which handles
OS-specific complications), and then add some code to it for the
emulated filesystem. FSEXT allows you to do just the latter, without
reinventing the wheel.
But if you think that providing FSEXT for symlinks complicates things
too much, let's not do that now. We could add that later, should
users want it.
- Raw text -