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

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

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

Julian Elischer-5
is this a topic for arch?


Julian



-------- Forwarded Message --------


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

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
>

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


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

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

freebsd-arch mailing list
First, I'm just an old guy, I don't maintain any systems (maybe a couple
of laptop's,) but no one holds me responsible if their work stations fail.

However very suddenly I have a contribution...

Do not worry about windoz or compatibility with windoz.  I assure you,
billygates and his gang never stayed up late worrying about how they
could keep the 'BSD boys happy.  Truth, the historical record is that
Microsoft made changes in their OS in order to break the programs of
alternative ISD'ers.  One example, Wordstar, Micropro was selling a
version for MS-DOS and when MS brought out their own
editor/word-processor, suddenly MS-DOS was changed in a way that, too
bad, the Micropro product wouldn't work on MS systems.   Indeed,
Micropro failed and eventually MS faced DOJ sanctions for such behavior.

So folks, just design and build the best you can.

Recently I got my wife a laptop running W10.  She's not a computer
person, in fact she hasn't used a computer for about fifteen years.  Now
she can.  So I discovered how it is, running W10.  (Bloated, and little
more than a vehicle for delivering advertisements to the user.)

If you want to support windoz, one last question, do you remember when
billy went around the country giving speeches telling people how wrong
it was to use open source programs?

I don't post here often.  So now I'm going to break the rules go off-topic.

First, friend up with the guys from OpenBSD.  Yes they can be, well not
jerks, just not overly social.  They have a lot to contribute.

Second, this business of giving chips the appearance of multiple cores
is nice if that's all you need/want.  But I think the world is looking
for an OS that goes way beyond, say, a mere hypercube. What is needed
are operating system architectures that can make use of many millions of
internet connected machines.

And the people behind FreeBSD are the right people to put something like
this together.


On 09/12/2017 08:55 PM, Julian Elischer wrote:

> is this a topic for arch?
>
>
> Julian
>
>
>
> -------- Forwarded Message --------
>
>
> 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).
>
> 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
>>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "[hidden email]"
>
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"


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

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

Julian Elischer-5
On 13/9/17 6:10 pm, Jules Gilbert via freebsd-arch wrote:
> First, I'm just an old guy, I don't maintain any systems (maybe a
> couple of laptop's,) but no one holds me responsible if their work
> stations fail.
>
> However very suddenly I have a contribution...

Hi Jules.
I was not saying we want to compete with microsoft, just that
Microsoft has set the bar as t o how long Asian users think a filename
can be. And as we are selligna file-server which is sending files to
windows, we need to be able to handle any filenames that the Windows
client sends to us.

>
> Do not worry about windoz or compatibility with windoz.  I assure
> you, billygates and his gang never stayed up late worrying about how
> they could keep the 'BSD boys happy.  Truth, the historical record
> is that Microsoft made changes in their OS in order to break the
> programs of alternative ISD'ers.  One example, Wordstar, Micropro
> was selling a version for MS-DOS and when MS brought out their own
> editor/word-processor, suddenly MS-DOS was changed in a way that,
> too bad, the Micropro product wouldn't work on MS systems.   Indeed,
> Micropro failed and eventually MS faced DOJ sanctions for such
> behavior.
>
> So folks, just design and build the best you can.
>
> Recently I got my wife a laptop running W10.  She's not a computer
> person, in fact she hasn't used a computer for about fifteen years. 
> Now she can.  So I discovered how it is, running W10. (Bloated, and
> little more than a vehicle for delivering advertisements to the user.)
>
> If you want to support windoz, one last question, do you remember
> when billy went around the country giving speeches telling people
> how wrong it was to use open source programs?
>
> I don't post here often.  So now I'm going to break the rules go
> off-topic.
>
> First, friend up with the guys from OpenBSD.  Yes they can be, well
> not jerks, just not overly social.  They have a lot to contribute.
>
> Second, this business of giving chips the appearance of multiple
> cores is nice if that's all you need/want.  But I think the world is
> looking for an OS that goes way beyond, say, a mere hypercube. What
> is needed are operating system architectures that can make use of
> many millions of internet connected machines.
>
> And the people behind FreeBSD are the right people to put something
> like this together.
>
>
> On 09/12/2017 08:55 PM, Julian Elischer wrote:
>> is this a topic for arch?
>>
>>
>> Julian
>>
>>
>>
>> -------- Forwarded Message --------
>>
>>
>> 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).
>>
>> 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
>>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "[hidden email]"
>>
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
>> To unsubscribe, send any mail to
>> "[hidden email]"
>
>
> .
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
>
>

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