I run a site of 10 hosts with many ports distfiles, NFS mounted on other hosts. Here's my actual example of how I hit the barrier, shown so folk won't think it's a contrived amount of links, it's simply my current site's NFS file system) : DIRECTORY SYMBOLIC LINK (or file, in last line) /usr ports -> /host/park/usr/ports /host park -> /a/park /a/park/usr/ports distfiles@ -> /pub/freebsd/distfiles/links / pub -> public / public -> site/public /site public -> domain/public /site/domain public -> this/public /site/domain this -> jhs.no_domain /site/domain/jhs.no_domain public -> ../../../host/flip/usr2/public /host flip -> /a/flip /a/flip/usr2 public@ -> ftp/public /a/flip/usr2/ftp/public/freebsd/distfiles/links/ gv-3.5.8.tar.gz -> /usr/ports/distfiles/cd.3.2/./gv-3.5.8.tar.gz /usr ports -> /host/park/usr/ports /host park -> /a/park /a/park/usr/ports distfiles@ -> /pub/freebsd/distfiles/links / pub -> public / public -> site/public /site public -> domain/public /site/domain public -> this/public /site/domain this -> jhs.no_domain /site/domain/jhs.no_domain public -> ../../../host/flip/usr2/public /host flip -> /a/flip /a/flip/usr2 public@ -> ftp/public /a/flip/usr2/ftp/public/freebsd/distfiles/links/ cd.3.2 ../cd.3.2 /a/flip/usr2/ftp/public/freebsd/distfiles 3.2-RELEASE/links /a/flip/usr2/ftp/public/freebsd/distfiles/3.2-RELEASE/links gv-3.5.8.tar.gz@ -> ../d4/gv-3.5.8.tar.gz /a/flip/usr2/ftp/public/freebsd/distfiles/3.2-RELEASE d4 -> link/d4 /a/flip/usr2/ftp/public/freebsd/distfiles/3.2-RELEASE link -> link.flip /a/flip/usr2/ftp/public/freebsd/distfiles/3.2-RELEASE link.flip -> ../../../../../../usr1/ftp/public/freebsd/ref/3.2-RELEASE/distfiles /a/flip/usr1/ftp/public/freebsd/ref/3.2-RELEASE/distfiles/d4 gv-3.5.8.tar.gz [ The real file ] Fix: Having searched all files in /usr/src for sysparam.h, I found just: sys/i386/boot/dosboot/fbsdboot.mak sys/i386/boot/dosboot/param.h:#include "sysparam.h" & both had Control Ms in (for Dos), it thus seems highly likely this quote "A path name lookup involved more than 8 symbolic links." was never correct, it should have read "32", & I've now increased it. Background Info: --- These can probably stay unchanged: sys/i386/boot/dosboot/sysparam.h:172 #define MAXSYMLINKS 8 gnu/usr.bin/rcs/lib/conf.h:46 #if has_readlink && !defined(MAXSYMLINKS) # if has_sys_param_h # include <sys/param.h> # endif # ifndef MAXSYMLINKS # define MAXSYMLINKS 20 /* BSD; not standard yet */ # endif #endif These use MAXSYMLINKS: gnu/usr.bin/rcs/lib/rcsedit.c resolve_symlink(L) lib/libc/stdlib/realpath.c: realpath(path, resolved) lib/libstand/nfs.c: nfs_open(upath, f) lib/libstand/ufs.c: ufs_open(upath, f) sys/kern/vfs_lookup.c: namei(ndp) sys/nfs/nfs_subs.c: nfs_namei(ndp, fhp, len, slp, nam, mdp, dposp, retdirp, p, kerbflag, pubflag) These use ELOOP: lib/libc/gen/errlst.c:114 "Too many levels of symbolic links" lib/libc/gen/exec.c:275 case ELOOP: lib/libc/sys/intro.2:354 A path name lookup involved more than 8 symbolic links. share/examples/mdoc/example.3: Too many levels of symbolic links. sys/sys/errno.h: #define ELOOP 62 lib/libc/stdlib/realpath.c if (++symlinks > MAXSYMLINKS) ) )--LBgkgox2pvUSLXLFBJZLsu9hcHoW9NYxV9Rogtt4alUkE1R0 Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" *** old/src/sys/sys/param.h Sat May 8 23:55:42 1999 --- new/src/sys/sys/param.h Tue Jul 13 23:10:21 1999 *************** *** 168,174 **** * infinite loops reasonably quickly. */ #define MAXPATHLEN PATH_MAX ! #define MAXSYMLINKS 32 /* Bit map related macros. */ #define setbit(a,i) ((a)[(i)/NBBY] |= 1<<((i)%NBBY)) --- 168,174 ---- * infinite loops reasonably quickly. */ #define MAXPATHLEN PATH_MAX ! #define MAXSYMLINKS 64 /* Bit map related macros. */ #define setbit(a,i) ((a)[(i)/NBBY] |= 1<<((i)%NBBY)) How-To-Repeat: I hit the problem doing md5 /usr/ports/distfiles/gv-3.5.8.tar.gz with the above set of links.
Committed change to man page (ELOOP) -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
State Changed From-To: open->analyzed The change sounds reasonable, but might have odd effect. Feedback from current mailing list is required I think.
Responsible Changed From-To: freebsd-bugs->n_hibma Remind me to close it in due time.
State Changed From-To: analyzed->closed Two people in the current mailing list viewed the example given as extreme and do not fancy upping the limit. I concur. That makes 3 againt and 1 in favour The change in the manpage should be sufficient to point at a possible location for fixing the problem in case someone runs into the same limitation.