Date: Mon, 10 Jun 2002 15:58:16 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: FSEXT hooks and symlinks
In-Reply-To: <3D048EF2.455CD32B@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1020610155657.25837B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Mon, 10 Jun 2002, Richard Dawe wrote:

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

True.  I think the file name passed to an FSEXT should be after symlink 
resolution, since FSEXT is conceptually called just before a system call, 
and DOS system calls don't know about symlinks.

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

If we remove the target of the link, it's a clear bug, yes.