On Fri, Nov 30, 2018 at 10:18 AM Eric Covener <[email protected]> wrote:
> On Fri, Nov 30, 2018 at 11:00 AM William A Rowe Jr <[email protected]> > wrote: > > > > The comment here makes no sense (unix, not windows). But the patch > itself seems reasonable. There is a performance hit, but nothing compared > to the call into stat/lstat. Other's opinions? > > Seems risky from regression POV. Safer to map errno of ENAMETOOLONG > to the APR_ENAMETOOLONG, in case APR_NAMEMAX is lower than actual > limit at runtime. > Which is the current implementation; /** @see APR_STATUS_IS_ENAMETOOLONG */ #ifdef ENAMETOOLONG #define APR_ENAMETOOLONG ENAMETOOLONG #else #define APR_ENAMETOOLONG (APR_OS_START_CANONERR + 3) #endif On Win32, in theory we can have longer 32k character file paths, but these were capped at 8k out of buffer space and other practical considerations. (This might be something to revisit in the future.) This correlates to your concern about new (regressive) limitations applied to Unix, in that we started with a saner limit and would only expand it, later on. For the time being, I'm happy if we drop this submission, unless it is shown that [l]stat on specific unix platforms will errors other than ENAMETOOLONG in response to such calls. My quick review of linux suggests it is fine as-is, as you suggested above. Not sure about httpd patch though, IIUC it only helps a faulty config > or module (dirwalk happening for long URI that won't actually be > served off disk) > But it is well understood that we can't remove the filesystem module, because it isn't modularized. I'm also not entirely comfortable with the httpd patch, but the not-found reaction isn't nonsensical (it isn't a file, so how would other modules like to behave?)
