Date: Tue, 11 Oct 2011 22:10:03 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-bugs@freebsd.org Subject: Re: kern/161481: mount fails with ENAMETOOLONG with path shorter than 255 // 1023 characters Message-ID: <20111011220032.T5922@besplex.bde.org> In-Reply-To: <201110110830.p9B8UADn054033@freefall.freebsd.org> References: <201110110830.p9B8UADn054033@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Oct 2011, Garrett Cooper wrote: > The following reply was made to PR kern/161481; it has been noted by GNATS. > > From: Garrett Cooper <yanegomi@gmail.com> > To: FreeBSD-gnats-submit@freebsd.org > Cc: Garrett Cooper <yanegomi@gmail.com> > Subject: Re: kern/161481: mount fails with ENAMETOOLONG with path shorter > than 255 // 1023 characters > Date: Tue, 11 Oct 2011 00:57:44 -0700 (PDT) > > I looked into this more closely after I submitted the bug and the problem > is the arbitrarily short value attached to MNAMELEN: > > 122537 mckusick #define MNAMELEN 88 /* size of > on/from name bufs */ > > The value has changed over the years (all the way back to the mid-90s) > from 90 to 70 to 80 to 88, but each time the author doesn't clearly state > why the change was required. It's part of the statfs(2) ABI. Perhaps other ABIs. It can only be reduced (as a hack to free space for other purposes), except when the ABI is changed. The ABI was last changed when struct statfs was expanded to hold 64-bit numbers even on 32-bit arches. Then the name fields were restored to approximately their original sizes. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111011220032.T5922>