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

From: Julian Elischer <>
Date: Wed, 13 Sep 2017 01:08:36 +0800
On 12/9/17 2:17 pm, Conrad Meyer wrote:
> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer <> 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 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 .  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).


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.


(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.)


> 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
Received on Tue Sep 12 2017 - 15:08:54 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC