Re: old bug: mount_nfs path/name is limited to 88 chars

From: Willem Jan Withagen <wjw_at_digiware.nl>
Date: Tue, 20 Jan 2015 01:14:46 +0100
On 19-1-2015 22:20, Garrett Cooper wrote:
> On Jan 19, 2015, at 8:46, Brandon Allbery <allbery.b_at_gmail.com>
> wrote:
> 
>> On Mon, Jan 19, 2015 at 10:44 AM, Anton Shterenlikht
>> <mexas_at_bris.ac.uk> wrote:
>> 
>>> So perhaps changing MNAMELEN will break statfs(2) on -stable
>>> too?
>>> 
>> 
>> I believe the context there is not so much "-current is special",
>> as "changing it for everyone is bad news" (and this would
>> necessarily need to originate in -current).
> 
> A compat layer needs to be created for all of the affected syscalls,
> and the change needs to be made. That’s it in a nutshell.
> 
> Doing it in 11 makes sense since there is a compat layer for 10 now…
> if I knew all of the steps I would happily do them as annoys me from
> time to time as well with the path length issue.

Well after this the next problem you'll be running into is:
  #define    PATH_MAX                 1024   /* max bytes in pathname */

Which I already did inf find(1) because the paths in backups of big
filesystems already bit in like 2011. Talked about it with Jilles, and
got more or less the same answer: You can up the value, but expect
things to break.

Which it did when I only fixed the size in find. It would break in the
program that got the path fed.
Never dared to just up the value, compile kernel/world, install and
reboot. And then see what comes of it.

So IMHO if possible this would need to be extended as well...

--WjW
Received on Mon Jan 19 2015 - 23:19:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC