"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > I like this solution as well! [sorry, I've had little time on my hands, > and no time to chime in on your earlier pleas for comment :-( ]
In all honesty I figured committing it was the best way to get your feedback :) Now I get to strike through the "close PR 10138 if nobody complains" task on my white board. > There are two other cases; the pre-queried or quick-stat'ed > r->finfo before we entered dir_walk's path parsing loop, and the > the initial lstat() leg, which we don't hit with this patch. [e.g. > only an APR_LNK that is re-stat()'ed is caught in this leg > of the code.] Do we need extra tests on those two legs, > as well? E.g. subreq_lookup_file may already have stat()ed > the file, or [per the group's request] we will try to stat() on > entry and save ourselves the effort within the loop. shrug for now... I'll try to think about it. > I don't know that I would be opposed to catching this in > apr_stat() as well. Sure, apr_file_open would succeed in > spite of the fact that apr_stat() fails, but the point to the > apr_file and apr_filepath functions were to normalize many > different OS'es into similar behavior. You wouldn't need to > actually stat() a file to reject from apr_open(), either. Simply > testing for a trailing slash would be sufficient. I can buy that argument. I'll put something in APR's STATUS file. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
