old bug: mount_nfs path/name is limited to 88 chars
Willem Jan Withagen
wjw at digiware.nl
Tue Jan 20 00:19:54 UTC 2015
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
More information about the freebsd-current
mailing list