Message-ID:	<399B954E.4BC4ECC@softhome.net>
Date:	Thu, 17 Aug 2000 09:33:34 +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: Symlinks & fstat
References:	<399B00B3 DOT 1AA2C454 AT softhome DOT net> <1858-Thu17Aug2000010725+0300-eliz AT is DOT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> 
> > Date: Wed, 16 Aug 2000 22:59:31 +0200
> > From: Laurynas Biveinis <lauras AT softhome DOT net>
> >
> > Not-yet-posted symlink code in fstat() needs serious reconsideration
> > with FSEXT support in readlink. The problem is that fstat() is yet
> > another function which needs to know how does a symlink look.
> 
> Sorry, I don't understand the problem.  Could you please elaborate?

fstat() needs to set S_IFLNK bit, somehow. Currently I do that with
saving current file position, seeking to the beginning, reading first
few bytes, comparing, restoring file position. Everything is pretty nice
until FSEXT comes to scene. If user provides hook for readlink(), all the
library recognizes his(her) symlinks. All the library except fstat(). Because
it has its own code and does not call readlink(). It may be worked around
with providing fstat() hook, but that's not something I would call clean
design.

Now if I provide 
int __internal_readlink(const char * path, int fhandle, char * buf, int max);

Here the relation between `path' and `fhandle' is like in _is_executable() - one and
only one has to be set. This function would have FSEXT hook, and would be called from
both readlink() and fstat().


> It isn't, unfortunately.  Except on plain DOS, the SFT either doesn't
> exist or is only partially simulated.

So I'm stuck with __internal_readlink(). BTW, if file was opened for write only,
__internal_readlink() would fail here, while SFT way would have little hope to
DTRT.

Laurynas

- Raw text -