You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by br...@apache.org on 2002/04/16 16:32:03 UTC
cvs commit: apr/include apr_errno.h
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.
Revision Changes Path
1.88 +1 -1 apr/include/apr_errno.h
Index: apr_errno.h
===================================================================
RCS file: /home/cvs/apr/include/apr_errno.h,v
retrieving revision 1.87
retrieving revision 1.88
diff -u -r1.87 -r1.88
--- apr_errno.h 4 Apr 2002 16:38:59 -0000 1.87
+++ apr_errno.h 16 Apr 2002 14:32:03 -0000 1.88
@@ -923,10 +923,10 @@
|| (s) == APR_OS_START_SYSERR + WSAENAMETOOLONG)
#define APR_STATUS_IS_ENOENT(s) ((s) == APR_ENOENT \
|| (s) == APR_OS_START_SYSERR + ERROR_FILE_NOT_FOUND \
+ || (s) == APR_OS_START_SYSERR + ERROR_PATH_NOT_FOUND \
|| (s) == APR_OS_START_SYSERR + ERROR_OPEN_FAILED \
|| (s) == APR_OS_START_SYSERR + ERROR_NO_MORE_FILES)
#define APR_STATUS_IS_ENOTDIR(s) ((s) == APR_ENOTDIR \
- || (s) == APR_OS_START_SYSERR + ERROR_PATH_NOT_FOUND \
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_NETPATH \
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_NET_NAME \
|| (s) == APR_OS_START_SYSERR + ERROR_BAD_PATHNAME \
Re: cvs commit: apr/include apr_errno.h
Posted by Branko Čibej <br...@xbc.nu>.
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.
It's a question of correct semantics. ENOTDIR means "This is not a
directory", and it's what you expect if, e.g., you try to rmdir a file.
ENOENT means "This bit doesn't exist".
Here's an example of what happened before this change; supposing that
"foo" does not exist:
| Unix | Windows
--------------------+--------+---------
apr_stat("foo") | ENOENT | ENOENT
apr_stat("foo/bar") | ENOENT | ENOTDIR
The APR_ENOTDIR result on Windows is semantically wrong.
In fact, it may be that the other codes in the Windows
APR_STATUS_IS_ENOTDIR should really be in ENOENT, too.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/include apr_errno.h
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/include apr_errno.h
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@xbc.nu> http://www.xbc.nu/brane/
Re: cvs commit: apr/include apr_errno.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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