From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Friday, November 09, 2001 10:15 AM
> [EMAIL PROTECTED] wrote: > > > > wrowe 01/11/09 00:08:43 > > > > Modified: server request.c > > Log: > > Reintroduce the 'one stat dir_walk' > > Bill, > > How confident are you that this is rock solid? i.e., should I consider > bumping it into 2.0.28? It would be great if we could have the > performance benefit, but IMO stability is the top priority for a beta > candidate tarball. Agreed that stability is key - and this is optimization, not essential. However, I don't mind incorporating it into .28. > Bill S. said he'd test it on Win32. I can test it on Linux and FreeBSD. Please, do. Then let's draw it up for a few hours on apache.org to really pound on it. It is entirely possible this introduces a hole, but I doubt it. I see about five cases that it could cause trouble... then I rewalk the code and realize that they are already protected against. Thinks like skipping the final stat, well, we already glom the final stat outside of that loop. Come to think of it, the only scenario I can picture is; user requests a symlink (the final filename component) we stat -> optimize the loop gets down to that last element/symlink we optimize away the actual stat to the target file That's badness, but it's the only scenario I can picture. What if we take it a step further, and test 'is this the end?' before we go and skip that last lstat. In this case, we can skip the lstat, but we musn't skip the actual stat. Stat'ing the final target, rather than lstat'ing it, is no good, we would end up with a stat - lstat - stat sequence that is a waste. Bill
