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