Message-ID: <399ACAE3.231BCAA8@softhome.net>
Date: Wed, 16 Aug 2000 19:09:55 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.74 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: djgpp-workers AT delorie DOT com
Subject: Re: FSEXT for readlink()
References: <399AA436 DOT AB592B7 AT softhome DOT net> <6480-Wed16Aug2000193507+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:
> 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.

Now I see that I need to use __FSEXT_call_open_handlers.

> The question is: what is such a ``primitive'' for our symlink
> emulation?

readlink() and symlink(). And imaginary FSEXT for symlinks user should
not go too smart and do nothing with __solve_symlinks().

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

Clear.

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

I think it will be not too hard for me, with things cleared up.

Laurynas