William A. Rowe, Jr. wrote:

> At 09:32 AM 4/16/2002, you wrote:
>
>> brane       02/04/16 07:32:03
>>
>>   Modified:    include  apr_errno.h
>>   Log:
>>   On Windows, ERROR_PATH_NOT_FOUND is an ENOENT, not an ENOTDIR -- 
>> same as OS/2.
>
>
> I'm somewhat dubious of this change.  Can you please point to the use 
> case
> (a specific scenario) that this existing define misbehaved?  The 
> greatest risk is
> that Apache -needs- to see ENOTDIR in the right times to avoid a ton 
> of extra
> effort, but most importantly, to make the right security decisions on 
> errors.
>
> Bill
>

I finally got some time to write a small test program, to compare the 
errors returned on Windows an Unix for various operations on 
(nonexistent) files and directories. The Unix variants I tried were 
HP-UX 10.20 and Solaris 7, where results were identical. I'm attaching 
the program itself and raw HP-UX and Win32 results.


First, the more interesting differences

    * open dir: Unix: SUCCESS, Windows: EACCES
      Not much can be done about this, and I don't think we should. This
      is a basic difference between the OS's. (Actually, you *can* open
      a directory as a file on Windows, but it's not something you'd
      want to do in normal circumstances. Well, you wouldn't want to do
      it on Unix in normal circumstances, either ...)

    * remove dir: Unix EPERM, Windows EACCES
      Basically the same result; I wonder, though, if it would make
      sense to include EPERM in APR_STATUS_IS_EACCES?

    * rmdir file: Unix ENOTDIR, Windows ERROR_DIRECTORY
      That's "The directory name is invalid" on Windows. Perhaps this
      code should be included in APR_STATUS_IS_ENOTDIR?


Now, the cases where the Unix status is ENOENT and the Windows status is 
ENOTDIR:

    open under noex
    mkdir under noex
    stat under noex
    remove under noex
    rmdir under noex

These are all tests where the parameter is a path (i.e., contains at 
least one path separator), and one of the components doesn't exist; this 
is what originally prompted me to make the change -- too hastily, I admit.

But it's exactly such cases that are giving me grief in Subversion on 
Windows, so I've been thinking what to do about them. Trying to get 100% 
correct codes would be a pain, because every time you got an 
ERROR_PATH_NOT_FOUND, you'd have to do a lot of extra stats. OTOH, if 
you want to make security decisions, you'd better have correct error 
information in the first place.

There's another, less clean solution: to include ERROR_PATH_NOT_FOUND in 
*both* APR_STATUS_IS_ENOENT and APR_STATUS_IS_ENOTDIR. This would fix 
the particular problem I'm having in Subversion, but might be a major 
PITA in other ways I'm not aware of.

Suggestions?

-- 
Brane Čibej   <brane@xbc.nu>   http://www.xbc.nu/brane/