> > > Well, it's an error that finds its roots in a call to > > > apr_filepath_merge with an argument of APR_FILEPATH_TRUENAME. > > > Looking at that function, it calls apr_filepath_root, which > > > tries to isolate the root in order to see whether it actually > > > exists. That scheme breaks down when there are no read/write > > > permissions.
> > The _TRUENAME flag tells us that we MUST use the canonical path. > > The *only* way to accomplish this is with read/traverse access > > through the file path. So, what are the ramifications of not passing that parameter? Will it "work" for those paths that are secured on the root? Is there another way to access the path without running into this problem, or any of the other problems the use of this parameter was no doubt implemented to avoid? Like I said, I don't think it's unreasonable to assume that a path is readable from the bottom up. I can think of several scenarios in which one would *not* want to grant access to the entirety of the path, and not all of those scenarios assume that the path is a network share. > I hope Brad got his answer; I'll move on. Brad got his answer, and it's perfectly acceptable to him, since he doesn't have the problem anymore. :) He'll leave it up to others to decide if they want to pursue it further. > Thanks for your time, Bill. Indeed, thanks for the explanation. Brad
