Date: Wed, 16 Aug 2000 19:35:07 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: lauras AT softhome DOT net Message-Id: <6480-Wed16Aug2000193507+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b CC: djgpp-workers AT delorie DOT com In-reply-to: <399AA436.AB592B7@softhome.net> (message from Laurynas Biveinis on Wed, 16 Aug 2000 16:24:54 +0200) Subject: Re: FSEXT for readlink() References: <399AA436 DOT AB592B7 AT softhome DOT net> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Wed, 16 Aug 2000 16:24:54 +0200 > From: Laurynas Biveinis > > 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.