Re: extending the maximum filename length (pointer to patch)[request for input]

On 12/9/17 2:17 pm, Conrad Meyer wrote:
> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer <julian_at_freebsd.org> wrote:
>> maybe we could get it into -current.
>> It'd be silly to have to have people re-inventing hte wheel all the time.
>> How about you put those changes into the reviews.freebsd.org and we can get
>> some general consensus on them.
>> We'll have to do similar for the Asian customers and anyone who uses UTF-8.
>> So it
>> would be silly to have to develop it all again (but subtly different of
>> course).
>>
>> The key issue is how many system calls and other APIs would be broken,
>> and how many would be broken in a non backwards compatible way?
>>
>> We would need it in a stable/10 and 11 branch but if the patch is isolated
>> enough we could carry it forward until we get to 12.
>>
>> One has to allow people to do whatever they are used to with Windows.
>> And in this case the issue is serving files over samba to windows machines.
> Hey Julian,
>
> I've thrown the patch up at https://reviews.freebsd.org/D12330 .  I
> haven't actually tested it on FreeBSD, but it does compile.  We also
> have some patches against contrib/pjdfstest to fix those tests against
> long file names, but I think we can hold off on those changes until
> we've nailed down what the architectural change will be (if any).

thanks!

that looks a lot like a proof -of concept patch we derived a while 
back but never really tested.
The issue for us is that using UTF-8 the filenames become too short 
for common usage in China and Japan.
Apparently they routinely nae files with the contents of a small novella.

e.g.

“这是一个测试多字符文件名长度的文件目的是命名一个文件用中文或者日文或者韩文字符并且要求字符长度超过八十五个字符然后拷贝该文件到我们的共享文件夹看看是否能够拷贝该文件到我.txt”
(I have no idea what that says but apparently it's a real filename from a windows machine that blew up when written via samba.)

Does anyone else have any thoughts about whether FreeBSD 12 might grow longer path/filename support?
  (I'm told Linux uses 1K and 4096 for filenames and path length.)

Julian

>
> It's quite possible this accidentally breaks even more APIs than
> expected and we should do some fine tuning to reduce the damage.  Our
> $WORK product mostly doesn't care about ABI, so we may not have
> noticed some ABI breakage.
>
> If anyone else is interested, please subscribe or add yourself as a
> reviewer on the phabricator revision.
>
> Best,
> Conrad
>