Re: patch to realpath(3) to make it DTRT(IMO) with variant symlinks

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Fri, Feb 06, 2004 at 04:45:12PM -0800, Matthew Dillon wrote:
> 
> :...
> :> quite probably not the best way, but it seems to work (it's been
> :> modestly tested.)  Other ways to address it might be:
> :> 
> :> - just don't make realpath resolve variant symlinks
> :> 
> :> I think that leaves the spirit (if not the letter) of realpath broken.
> :> Existing scripts expect realpath(1) to return a real genuine filename.
> 
>     realpath() is used to resolve paths, so I would say that it *should*
>     resolve varsyms.
>  
> :> - make readlink(2) resolve variant symlinks instead
> :
> :IMO this is the correct way.
> 
>     No, we can't do this.  Many programs use symlinks to store binary or
>     near-binary data.  It has to be WYSIWYG.  And, besides, when you ls -lda
>     a symlink you want to see the ${}'s, not the post-resolved data.

Sorry, must have been sleeping there. You are 100% correct. I don't
want to do it otherwise.

I should stop thinking about anything more than cosmetical changes after
a hard day ;-)

> 
> :> - make varsymreplace a syscall
> :> 
> :> Too rich for my blood :)  Could be better for consistency though (e.g.
> :> my patch doesn't check vfs.varsym_enable; it probably should.)
> :
> :I don't like that one too. If Matt doesn't cry out loud, I'll change
> :the kernel source to allow them to share the implementation.
> :
> :Joerg
> :> -Chris
> :
> 
>     Huh?  No new syscall is needed as far as I can tell.  realpath() is the
>     only procedure which might conceivably need to resolve a varsym.

I don't want to add syscall, but change kern_varsym.c to allow inclusion in
the libc. I want to avoid having to implementations of the resolution
algorithm if I can.

Joerg

> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>