On 02/04/2014 04:06 AM, Daniel P. Berrange wrote: >> >> v9fs need use "mkdir, remove ..." which have MAX_PATH limitation. So if >> the combined path is longer than MAX_PATH, before it passes to "mkdir, >> remove ...", it has to be truncated just like what rpath() has done. > > I don't believe you are correct there. Those functions should > return "errno == ENAMETOOLONG - pathname was too long". The > MAX_PATH constant is not even required to exist in POSIX, so > I would not expect the spec to mandate anything about MAX_PATH > in relation to those functions. > > Copying Eric who is involved the POSIX spec group to confirm. >
Correct - POSIX intentionally allows GNU Hurd behavior which is no MAX_PATH. You can use openat() and friends to reduce the path length of an operation you are trying, and there, your limit becomes NAME_MAX (255 on many filesystems, but also a value that POSIX allows to be undefined). POSIX merely requires that the system be consistent - it cannot toggle between ENAMETOOLONG errors through one interface and acting on the name through another. > Even if they are limited, it is still better practice to use > dynamic allocation for this, over fixed length buffers IMHO. Agreed on two counts - dynamic allocation is essential on platforms where MAX_PATH is undefined and thus where path names can be constructed that occupy longer than a system page (because you do NOT want stack allocations longer than a page); and you WANT to try the system call because an ENAMETOOLONG from the system is definitive whereas giving up early because you only guess that it will be too long or because you used snprintf and truncated the string generally causes confusion. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
