Date: Wed, 26 Jun 2002 17:33:57 +0100
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: The Bat! (v1.60h) Personal
X-Priority: 3 (Normal)
Message-ID: <161256143054.20020626173357@softhome.net>
To: rich AT phekda DOT freeserve DOT co DOT uk
CC: DJGPP workers <djgpp-workers AT delorie DOT com>, eliz AT is DOT elta DOT co DOT il
Subject: Re: FSEXT hooks and symlinks
In-Reply-To: <3D048EF2.455CD32B@phekda.freeserve.co.uk>
References: <3D048EF2 DOT 455CD32B AT phekda DOT freeserve DOT co DOT uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jun 2002 15:35:02.0781 (UTC) FILETIME=[09F582D0:01C21D27]
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


> Hello.

> I've just been looking at the FSEXT hooks code. I noticed that symlinks are
> not handled consistently. Should the symlink be resolved, before calling a
> function that takes a path name? For instance compare
> src/libc/ansi/stdio/remove.c and src/libc/posix/sys/stat/lstat.c. lstat.c
> passes the FSEXT the resolved name. remove.c passes the FSEXT the original
> name. I haven't looked at any other cases, but I think the FSEXT docs should
> be more clear on what kind of filename an FSEXT can expect to have passed into
> it.

As I see it - FSEXT should operate on the same thing caller function
does. I.E. If open() is aware of symlinks then it should pass resolved
name to FSEXT. If _open() is not, it should pass original name.

> Actually, I have another question. How do we remove symlinks using libc?
> According to the unlink man page on RedHat Linux 6.2 unlink() should remove a
> symlink. But looking at the code for remove (and hence unlink) in our libc, it
> looks like it will always remove the target file. I think this is a bug.

I was aware that remove() operates on files themselves. I was confused
until I found this little gem piece of evidence:

http://www.delorie.com/archives/browse.cgi?p=djgpp-workers/2000/08/23/08:08:43

Here is the relevant quote by Eli:

   - remove, rename, rmdir, unlink: these are indeed documented not to
     follow symlinks, but this refers to the last part of the file
     name, I think, not to its directory part.  For example, this
     call:
           remove ("/foo/bar/baz/file");

     should resolve symlinks in "/foo/bar/baz", in case one or more of
     them are symlinks.  Otherwise, `remove' will fail, because the
     low-level DOS functions it calls don't know about symlinks.

So I have two functions for solving symlinks: _solve_symlinks()
which returns 100%-symlink-clean-path and _solve_dir_symlinks() which
resolve symlinks everywhere but in the last component of the path.
Which is used in the case of remove and alike. I think I screwed
up choosing the latter function name...

Laurynas