On 02/04/2014 09:12 PM, Eric Blake wrote:
> On 02/04/2014 05:25 AM, Markus Armbruster wrote:
>
>> Second guessing when a pathname is too long for a system call is not a
>> good idea. If it's too long, the system call will tell you. As Dan
>> noted, PATH_MAX is *not* a hard limit.
>>
>> {PATH_MAX}
>> Maximum number of bytes the implementation will store as a
>> pathname in a user-supplied buffer of unspecified size,
>> including the terminating null character. Minimum number the
>> implementation will accept as the maximum number of bytes in a
>> pathname.
>
> Linux allows unbelievably long absolute names. Jim Meyering proved with
> coreutils that you can create an absolute name well over a megabyte in
> length. The trick is that you have to access it via relative names
> where each relative name is PATH_MAX or less (that is, the Linux kernel
> refuses to operate on more than a page at a time when doing file name
> resolution), by using openat() and friends. mkdirat() can create a
> directory with an absolute name longer than PATH_MAX, even if mkdir() can't.
>
OK, thank all of you, what you said sound reasonable to me. I don't
know why the original author/maintainer did not support 'unlimited'
path, so better to get original authors' opinion.
And can we split current discussion into 2 pieces:
- fix sprintf() bug, can use snprintf() to fix it just like other
places have done -- apply this patch (comments need be improved).
- improve 9pfs features -- support 'unlimited' path internally.
before do it, better to get original authors' response firstly.
I guess, we need change quite a few areas and have a full test.
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
