Symlink indirection
Amos Waterland
apw@us.ibm.com
Fri Dec 13 09:16:00 GMT 2002
I think that you and Richard are dicussing a slightly different issue
than the original poster asked about. The original question was:
On Fri, 13 Dec 2002, Andrew Walrond wrote:
> Is the number of allowed levels of symlink indirection (if that is the
> right phrase; I mean symlink -> symlink -> ... -> file) dependant on the
> kernel, or libc ? Where is it defined, and can it be changed?
To which Richard replied:
> Since a symlink is just a file containing a name, the resulting path
> length is simply the maximum path length that user-space tools allow.
> This should be defined as "PATH_MAX". Posix defines this as 255
> characters but I think posix requires that this be the minimum and all
> file-name handling buffers must be at least PATH_MAX in length.
>
> A hard link is just another directory-entry for the same file. This,
> therefore follows the same rules. There must be enough space on the
> device to contain the number of directory entries, as well as enough
> buffer length in the tools necessary to manipulate these "nested"
> directories, which are not really "nested" at all.
But Richard is not actually completely correct. There is a limit of 5
levels of symlink indirection in vanilla 2.4 series Linux kernels.
% touch 0
% for i in `seq 1 10`; do ln -s `ls | sort | tail -1` $i; done
% ls
0 1 10 2 3 4 5 6 7 8 9
% cat 5
% cat 6
cat: 6: Too many levels of symbolic links
% strace cat 6 2>&1 | grep 'open("6",'
open("6", O_RDONLY|O_LARGEFILE) = -1 ELOOP (Too many levels of symbolic links)
This has been discussed by Al Viro et al. many times on lkml. I believe
that it is not a user-space or POSIX issue, but rather a kernel issue.
Thanks.
Amos Waterland
More information about the Libc-alpha
mailing list