freebsd stable - Jan 2015 - old bug: mount_nfs path/name is limited to 88 chars

Anton Shterenlikht wrote:
> This bug:
> 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.)

However, this can't be done in -current because it breaks
the statfs(2) syscall API, etc.

There is a patch in projects/ino64 to try and change ino_t
to 64bits and I think it also included changes for this.
- It would need a new statfs(2) syscall and versioned library
  routines for everything that uses statfs(2) in libc, etc.

So, for -current the answer is "it is not easy".

There was a patch floating around that truncated the path
to 64bits, so that the mounts are allowed but not reported
correctly via statfs(2). You can probably find that patch
and use it, if a broken statfs(2) isn't a problem for you.

rick
> Thanks
> 
> Anton
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
>

>From rmacklem at 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