I want to make it clear here that I have never used Reiser4, so on a personal level the issue is somewhat academic.

On 9-Sep-04, at 1:11 AM, André Malo wrote:

SUSv3/POSIX disagrees as well. So I think, Mr. Reiser should just fix,
what's broken. It's not such an uncommon case to test an arbitrary file
path, if it's possible to open it.

So, Apache is only going to work on POSIX systems, you're saying?

Even under POSIX, there are cases where this particular piece of error analysis could fail. For example, the redundant open on pathname/.htaccess could return ENAMETOOLONG even though pathname was within limits and names a regular file. (Admittedly, that is a pathological case, but...)

EACCES is just the wrong error, because it has different semantics.

I tend to agree, but it's not totally clear. Reiser4's files can also function as directories, so ENOTDIR is incorrect. ENOENT seems like a reasonable choice, but POSIX also mandates the return of EACCES instead of ENOENT if search permissions are not present. I don't know enough about the Reiser filesystem to know how one specifies search permissions on a file which can also be a directory.


It is worth noting that in the particular circumstances which give rise
to this error, ap_directory_walk could tell if the path refers to a
directory or a file; it should be possible to avoid walking too far,
although there may well be edge cases I haven't thought of.

-> Race condition.

What about just changing line 930 of server/request.c from

           if (r->finfo.filetype
to

           if (r->finfo.filetype && *r->path_info

All that will do is not optimise on the last segment; I don't see how not performing the optimization could create a race condition that didn't already exist.



Reply via email to