Julian Elischer
2017-09-13 00:55:41 UTC
is this a topic for arch?
Julian
-------- Forwarded Message --------
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
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"
Julian
-------- Forwarded Message --------
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,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.
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).
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
_______________________________________________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
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"