Re: Recursion level of symlinks limitted to five?

Re: Recursion level of symlinks limitted to five?

[Junio Hamano]

>>>>> "david" == david parsons <o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s> writes:

david> In article <linux.kernel.7v4snva2bj.fsf@shine.twinsun.com>,
david> Junio Hamano  <junio@twinsun.com> wrote:
>> Just out of curiosity, couldn't the resolving of symlinks all be
>> done in the userland? 

david>    A libc solution requires that everyone use a libc that's been
david>    hacked to do this, umm, method, and not everyone will hack their
david>    version of libc to do that.

Agreed, and that's part of my idea.  If non-insignificant number
of people feel that 5 levels of symlinks are too few for
real-world applications, either (1) they rewrite their
application so that it catches ELOOP whenever they call system
calls and resolve symlink as needed, or (2) fold such a
check-and-recover scheme into the standard C library so that
application programmers do not have to worry about this
limitation over and over again.  The key idea here is to fold
this into the standard C library, not to replace the C library
with your hacked one.

When (2) happens, but until everybody updates to the new C
library, applications running on a configuration where they do
not see more than 5 levels of symlink indirection work fine with
both the old and new C library, and in addition, applications
running with the new C library would not even see 5-level
restriction imposed by the kernel.  Of course, userland C
library would still have its own limits, depending on the way
the memory needed to recursively resolve symlinks are allocated.
Over time, everybody would update their C library if the above
makes into the standard C library.

When that happens, there is no reason for the kernel to even
support 5 levels of indirection.  The kernel could even return
ELOOP when it sees just one symbolic link and let the C library
resolve the symlink.  Of course, on the other hand, we may want
to have the kernel resolve some levels of indirection itself
for, say, performance reasons.  But an important point of the
idea outlined above is that it makes how many symlink
indirections a typical application expects to be supported by
the kernel irrelevant when the kernel implementor decides how
many levels of symlinks are supported by the kernel.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/