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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Anderson-2
On 12 Sep 2017, at 14:38, Julian Elischer wrote:

> “这是一个测试多字符文件名长度的文件目的是命名一个文件用中文或者日文或者韩文字符并且要求字符长度超过八十五个字符然后拷贝该文件到我们的共享文件夹看看是否能够拷贝该文件到我.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.)

Google Translate says, amusingly:
"This is a test file for the length of the file name. The purpose is to
name a file in Chinese or Japanese or Korean characters and require the
character to be longer than 85 characters and then copy the file into
our shared folder to see if it can copy the file To me" (.txt, I guess)

No matter what number you choose for a path length, you're never going
to win against that specific user. :)


Jon
--
Jonathan Anderson
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Ben RUBSON
On 12/9/17 2:17 pm, Conrad Meyer wrote:

> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer <[hidden email]> 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).

Hi Conrad,

This patch makes me think about another related bug #184340 :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340
It is about PATH_MAX which in some cases can be too small.

Not sure if it's the case / and how to do it,
but perhaps it is time to raise some other limits /
think about a global solution regarding these length limits ?

Many thanks !

Ben

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Rainer Duffner

> Am 12.09.2017 um 23:11 schrieb Ben RUBSON <[hidden email]>:
>
> On 12/9/17 2:17 pm, Conrad Meyer wrote:
>> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer <[hidden email]> 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).
>
> Hi Conrad,
>
> This patch makes me think about another related bug #184340 :
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340>
> It is about PATH_MAX which in some cases can be too small.
>
> Not sure if it's the case / and how to do it,
> but perhaps it is time to raise some other limits /
> think about a global solution regarding these length limits ?
>
> Many thanks !
>
> Ben



And there’s also this bug:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067>

"g_dev_taste: make_dev_p() failed on importing pool with snapshots with long names“



But maybe that has nothing to do with it.






_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

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

Conrad Meyer-2
In reply to this post by Ben RUBSON
On Tue, Sep 12, 2017 at 2:11 PM, Ben RUBSON <[hidden email]> wrote:

> Hi Conrad,
>
> This patch makes me think about another related bug #184340 :
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340
> It is about PATH_MAX which in some cases can be too small.
>
> Not sure if it's the case / and how to do it,
> but perhaps it is time to raise some other limits /
> think about a global solution regarding these length limits ?
>
> Many thanks !

Hi Ben,

Yes, I think that bug is about basically the same issue under discussion here.

Best,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"