Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3D052A8B.9130E7EF@phekda.freeserve.co.uk>
Date: Mon, 10 Jun 2002 23:39:07 +0100
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: FSEXT hooks and symlinks
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020610155657 DOT 25837B-100000 AT is> <1023716516 DOT 31679 DOT 5 DOT camel AT bender DOT falconsoft DOT be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

[slight reordering]
> Eli Zaretskii wrote:
>
> > Richard Dawe wrote:
> >
> > > 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.

Tim Van Holder wrote:
[snip]
> OTOH, as stated below [richdawe: above], 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).
[snip]

I'm not sure that remove() should act on the symlink itself. ANSI C has no
concept of symlinks as far as I know. The behaviour should be like this, I
guess:

unlink: removes the symlink, i.e. doesn't dereference the symlink
remove: removes the target of the symlink, i.e. resolves the symlink

Currently unlink just calls remove. Here's what I think we should do:

* Split remove into two functions: remove, which does the symlink resolution
and calls the FSEXT handler, if any, then calls the second function, if
needed; __remove_internal that does the actual removing.

* Make unlink call the FSEXT handler, if any, then call __remove_internal, if
needed.

In both cases the FSEXT handler would be called for function __FSEXT_unlink.

I can conceive of a filesystem that allows unremoveable symlinks. In that case
unlink on a symlink would fail, but remove could succeed, if the target of the
symlink were removeable.

Does this behaviour make sense?

Thanks, bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]