Subject: Re: FSEXT hooks and symlinks
From: Tim Van Holder <tim DOT van DOT holder AT pandora DOT be>
To: djgpp-workers AT delorie DOT com
Cc: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
In-Reply-To: <Pine.SUN.3.91.1020610155657.25837B-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020610155657 DOT 25837B-100000 AT is>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 10 Jun 2002 15:41:55 +0200
Message-Id: <1023716516.31679.5.camel@bender.falconsoft.be>
Mime-Version: 1.0
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, 2002-06-10 at 14:58, Eli Zaretskii wrote:
> 
> 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.

OTOH, as stated below, remove() should be acting on the symlink, not the
target, so I expect passing the symlink, not the target, to the FSEXT
would be correct in that case (if we need to pass it to the FSEXT at
all).

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