symlinks follow 8 or 5?
Hi,
do_follow_link comments is "This limits recursive symlink follows to 8"
... but having (x=1->10) ln -s x+1 x and trying cat 1 just works for x < 7 which drops follow mode to 5.Is this irrelevant ?
Regards,
FabF
FabF <[email protected]> said on Thu, 29 Jul 2004 07:34:39 +0200:
Quoted 4 lines
Hi,
do_follow_linkcomments is "This limits recursive symlink follows to 8"
... but having (x=1->10) ln -s x+1 x and trying cat 1 just works for x < 7 which drops follow mode to 5.Is this irrelevant ?
This popped up a few years ago.
http://www.ussg.iu.edu/hypermail/linux/kernel/9903.1/0018.html
Obviously, nothing came about it. And I suspect the problem (running out of stack space) is even worse these days with 4k stacks. Why is this even done recursively?
Note that 5 symlinks is quite a burden. I got hit by it a few days ago with my farm of symlinks between nfs RAID disks and my home directory (~/raid points to /nfs/cluster, papers refers to ~/raid/papers, Astro-ph refers to ~/papers/Astro-ph, and then I autofs shfs mounted ~/ from another host, which involve a couple of symlinks again (/host to /mnt/nfshost and /mnt/nfshost to /var/autofs/misc/host and ~/host to /host - the first two so that when the network goes down, all I have to do is remove (by script) /mnt/nfshost, and then autofs wont try to mount something it can't when something tries to access ~/host)).
Signature · 2 lines
TimC -- http://astronomy.swin.edu.au/staff/tconnors/ "We must use Tim as a tool, not as a couch." -- J F Kennedy
Quoted 2 lines
Obviously, nothing came about it.
you haven't been paying attention.... the current 2.6 kernels have a patch series that is fixing this for most filesystems already with the last few others in progress.
Quoted 2 lines · Arjan van de Ven
you haven't been paying attention.... the current 2.6 kernels have a patch series that is fixing this for most filesystems already
Which reminds me: how can we safely determine whether this is implemented for a local filesystem from userland? Unless we can do I cannot change the value of SYMLOOP_MAX and people will not be able to take advantage of the raised limit safely.
Signature · 1 line
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Quoted 9 lines · Ulrich Drepper
Quoted 2 lines · Arjan van de Ven
you haven't been paying attention.... the current 2.6 kernels have a patch series that is fixing this for most filesystems already
Which reminds me: how can we safely determine whether this is implemented for a local filesystem from userland? Unless we can do I cannot change the value of
SYMLOOP_MAXand people will not be able to take advantage of the raised limit safely.
well actually it can't be per userland; it's just that we're almost at the point where all filesystems are switched to the new infrastructure so that the global constant can be bumped to 8 again...
Quoted 10 lines · Arjan van de Ven
Quoted 5 lines · Ulrich Drepper
Which reminds me: how can we safely determine whether this is implemented for a local filesystem from userland? Unless we can do I cannot change the value of
SYMLOOP_MAXand people will not be able to take advantage of the raised limit safely.well actually it can't be per userland; it's just that we're almost at the point where all filesystems are switched to the new infrastructure so that the global constant can be bumped to 8 again...
Well, one can test it from userland - make a tempdir and create progressively longer link chains until it fails. Quirky, sure.
Helge Hafting