current status RE: "File name too long" issues

[Bruce Evans]

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