Re: Realpath & context sensitive symlinks

[Michael Eager <eager at mvista dot com>]

Michael Eager wrote:
> 
> I looked through the Glibc archive but didn't see any comments on this.
> 
> Some file systems (like GFS) support context dependent symlinks (CDSL).
> Thesesymlinks contain macros like {os} or {uid} which get substituted with
> the appropriate value to create an actual path name.  This macro
> substitution only occurs when the file system is following a symlink,
> otherwise the macro is left unmodified.
> 
> Realpath (canonicalize) doesn't know anything about these macros.
> When it finds one of these CDSLs, it treats it like a regular text
> symlink, and sticks it in the path.  Lxstat fails on this path, since
> it contains funny text and isn't a real path.
> 
> Anyone got a solution to this?  Or suggestions?

Let me summarize the comments I've heard and my thoughts:

GFS and some other file systems provide non-path text in their symlinks.
It seems like an odd thing to do, doesn't really seem necessary, and it
breaks things like 'realpath'.  On the other hand, it seems to conform
to POSIX.  Saying don't use GFS doesn't resolve the problem.

Linux doesn't provide resolvepath.  Adding it might be a good idea,
but looks like overkill.

GFS doesn't provide an obvious way to convert from the symlink text to 
a real path.  The translation is pretty simple, and hard-coded, but it
isn't clear that all CDSL file systems have the same macros, same formats,
or same translations.  

Walking the directories tree looking for matching inodes is slow.
Worse, since each of the opendir and readdir calls can be interrupted,
it's possible that the file system may change while reading directories.

The sequence chdir, getcwd, chdir back, can be interrupted, with the
possiblity that there might be no directory to return to.  Getcwd is a 
system call, and it walks the directory tree cache entries, which is 
both more efficient and less interruptable.  There are also circumstances 
where this doesn't work:

   ln -s /foo/{uid}/bin/x x
   ls -l x
   ....   x -> /foo/{uid}/bin/x

   If you read the link for x, and extract the directory, it isn't a 
   valid path and you can't chdir to it.  

Another thought is that GFS should modify readlink to return a
translated path.  This would let realpath work OK.   But this seems
to be different from what POSIX intended and you wouldn't be able
to distinguish between a link to /user/500/bin and /user/{uid}/bin/.

--
Michael Eager     eager@mvista.com	408-328-8426	
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA  94085