Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E43F543.EC75DCB8@phekda.freeserve.co.uk>
Date: Fri, 07 Feb 2003 18:04:51 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: FSEXT hooks and symlinks
References: <3D048EF2 DOT 455CD32B AT phekda DOT freeserve DOT co DOT uk> <161256143054 DOT 20020626173357 AT softhome DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Going back a bit here...but I think we handle FSEXTs wrongly in the code for
remove.

Laurynas Biveinis wrote:
[snip]
> 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.
[snip]
> 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.

It looks like we pass the unresolved filename to the FSEXT handler for unlink
in src/libc/ansi/stdio/remove.c:

  /* see if a file system extension wants to handle this */
  if (__FSEXT_call_open_handlers_wrapper(__FSEXT_unlink, &rv, fn))
    return rv;

  /* Handle symlinks */
  if (!__solve_dir_symlinks(fn, real_name))
    return -1;

  /* Get the file attribute byte.  */
  attr = _chmod(real_name, 0);

I think the __FSEXT_call_open_handlers_wrapper call should be after the
__solve_dir_symlinks call. Is it OK to change them around?

Bye, Rich =]

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