Mail Archives: djgpp-workers/2003/02/07/18:20:51
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/ ]
- Raw text -