Date: Mon, 19 Jan 2015 07:44:26 -0800 (PST) From: Anton Shterenlikht <mexas@bris.ac.uk> To: mexas@bris.ac.uk, rmacklem@uoguelph.ca Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: old bug: mount_nfs path/name is limited to 88 chars Message-ID: <201501191544.t0JFiP7O027952@mech-as221.men.bris.ac.uk> In-Reply-To: <1401700998.16283447.1421681564732.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
>From rmacklem@uoguelph.ca Mon Jan 19 15:37:25 2015 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167105 >> >> is a show stopper for me. The path/name length is >> beyond my control, so I cannot make it shorter. >> >> This discussion seems inconclusive: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2012-April/038543.html >> >> Is there no easy solution to this PR? >> Or is there no interest in fixing the issue? >> >Well, the "easy" solution is to just increase the value >of NNAMELEN and rebuild everything from sources to use >the modified sys/mount.h. (If you can run a modified >system built entirely from sources, I think you can do >this.) I can do this on several 10.1-stable systems, but I understood from the email trail that there is no guarantee that nothing will be broken by such change. I know there is never a guarantee, but.. >However, this can't be done in -current because it breaks >the statfs(2) syscall API, etc. Even on 10.1-stable I see in statfs(2): #define MNAMELEN 88 /* size of on/from name bufs */ So perhaps changing MNAMELEN will break statfs(2) on -stable too? Anton
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201501191544.t0JFiP7O027952>