Date: Thu, 19 Feb 2015 21:27:50 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org, Konstantin Schukraft <konstantin@schukraft.org> Subject: Re: current status RE: "File name too long" issues Message-ID: <20150219203111.W4301@besplex.bde.org> In-Reply-To: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> References: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Feb 2015, Rick Macklem wrote: > Konstantin Schukraft wrote: >> I just realised I only sent this email to freebsd-questions@, I >> ... >> - -------- Forwarded Message -------- >> ... >> this seems a rather old issue that's still alive, manifesting in NFS >> mounts, nullfs mounts with jails, etc: >> "Overly" long path names in these situations result in an error like >> "mount_nullfs: <path>: File name too long". I, for example, run into >> this every time I try to setup a poudriere jail, others seem too. >> >> Since the forums didn't really provide an answer, I'll ask here: >> Is there work currently being done on this issue? Because this reply: >> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=210593+0+/usr/local/www/db/text/2014/freebsd-questions/20141221.freebsd-questions >> seems to indicate this has been fixed, which definitely isn't the >> case >> for many people, including myself. >> >> So what's the status on that? Am I overlooking something important? >> > As far as I know, the 88 byte limit for paths still applies. > You can easily change the value of MNAMELEN in sys/sys/mount.h and > rebuild everything from these modified sources. mount() used to work. The saved pathname in the statfs struct is only informational, but mount() has been broken to make this the limit on the syscall. This doesn't even work to give a uniform limit, since some file systems save the path in the superblock and have more or less space than MNAMELEN for this, depending on the file system. > However, FreeBSD cannot do this, since it breaks the statfs(2) syscall > interface and users of it. Unbreaking mount() doesn't break the ABI. Of course, everything using struct statfs can only display a truncated name, and there is no alternative to using struct statfs since the name is not saved anywhere else. Except sometimes in superblocks, but there is no user API to fetch the name from there. > In svn's projects/ino64, there is work in progress on this + changing > ino_t to be 64bits. Hopefully this work will make in it FreeBSD11. > If there is a new system call that replaces the current statfs(2) that > ends up with a different name, it might be possible to MFC this and > have statfs(2) return a truncated path. > > I believe there is a patch floating around that allows NFS mounts > with longer paths to work, truncating the path for statfs(2), but > this is not in -current etc. BSD-old through FreeBSD-4 does this without any patch. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150219203111.W4301>