> In article <Pine.GSO.3.96.980420113705.27291B-100000@csb>,
> Adam D. Bradley <artdodge@cs.bu.edu> wrote:
> >
> >I took a look at how FreeBSD does it... apparently, when in their
> >equivalent of lookup_dentry(), when they discover a symlink component
> >in the pathname they overwrite it in-place with the symlink's "value",
> >then re-start the resolution process using the new name (w/o changing
> >"base"). If expanding a symlink would cause the buffer to overflow,
> >they return -ENAMETOOLONG. Simple, graceful, makes sense, and allows
> >"max-symlinks" to be implemented as a simple, flat counter/countdown.
>
> And means that you can't handle the name in-line,
That's a common problem with almost all of the flat algos I looked at,
except for the linked-list one, which has its own kinds of overhead.
> nor that you can allow
> the low-level filesystem to have its own "follow_link()".
I'm thinking about this one. Perhaps it would make sense to change
the semantics of readlink() and follow_link() somewhat; f.e., if there
is no "follow_link()", then we can assume that all symlinks are just
symbolic names that can be used as described (since this is
essentially what most fs's w/ symlinks do anyway); if there is a
readlink() AND a follow_link(), then either default to the old
behavior or allow readlink to return a flag (a call-by-reference
parameter) indicating that its value can not be trusted as an _actual_
filename (e.g., /proc/#/fd entries, etc) and that follow_link should
be used.
> In addition, it puts a rather bad length-restriction on symlinks.
>
> Quite frankly, I'd ratehr have a _reliable_ nesting level counter like
> Linux already has rather than the above thing. Especially the name
> length thing makes the above extremely unpredictable: some symlinks work
> fine, while others fail. In fact, the _same_ symlink can work or fail
> depending on where you happen to be using it - even with no nesting at
> all.
These are indeed problems - it's _very_ easy to imagine pathological
cases for this, which is why I've been beating my head against walls
wondering which approach to try coding first.
However, I don't think the pathological case is as restrictive as we
would first imagine, IF it is guaranteed that no "real" absolute
filename can exceed PATH_MAX in length. Given that assumption, the
only case I could come up with that can provoke a "superfluous"
ENAMETOOLONG is where there is some "transitory" name (i.e., a symlink
in the name has been 'expanded') with a component which is a symlink
that will eventually be _shrunken_ by a symlink 'expansion'. (Also
bear in mind that once a component of the filename is successfully
looked up, it is no longer needed and can be overwritten by subsequent
symlink expansions.)
Another option to consider: if an expansion would provoke
ENAMETOOLONG, fall back on to calling follow_link (or, with the
changed semantics mentioned above, fall back to a recursive iteration
of lookup_dentry)
> In short, I think the FreeBSD solution is a _lot_ worse than the Linux
> one.
You're probably right of course, but I want to exhaust the variations
on it thoroughly to be sure ;-) I, too, would rather do this The
Right Way, but I'm not convinced that the current scheme is it. I'm
also not enamoured of the scheme I'm playing with, so if anyone has a
better suggestion...
Adam
PS - Congratulations on v3.0!
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu