Message-ID: <399B954E.4BC4ECC@softhome.net> Date: Thu, 17 Aug 2000 09:33:34 +0200 From: Laurynas Biveinis X-Mailer: Mozilla 4.74 [en] (Win98; U) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > > Date: Wed, 16 Aug 2000 22:59:31 +0200 > > From: Laurynas Biveinis > > > > 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