You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Mats Nilsson <ma...@xware.se> on 2001/08/06 19:20:29 UTC
Report of incorrect behaviour of apr_dir_read on win32
Hi
During my testing the subversion (http://subversion.tigris.org) on the
Win32 platform, I ran into some problems with the apr_dir_open/apr_dir_read
functions as implemented on Win32.
The following is tested on a WinNT 4.0 sp6, using MSVC6 sp3.
As for which version of APR I'm using, I can't really tell. However, I
retrieved a APR CVS snapshot in april, and file_io/win32/dir.c has version
1.56.
This test program demonstrate these problems:
----- snip
#include "../apr/include/apr_pools.h"
#include "../apr/include/apr_file_info.h"
#include <assert.h>
void test(const char *dirname) {
apr_pool_t *pool; apr_pool_create(&pool, NULL);
apr_dir_t *dir;
apr_status_t err;
apr_finfo_t this_entry;
err = apr_dir_open(&dir, dirname, pool);
/* Problem 1:
* This call fails when dirname == "c:/temp", but not when it is "c:\\temp"
*/
err = apr_dir_read(&this_entry, APR_FINFO_NORM & ~APR_FINFO_IDENT, dir);
assert(APR_STATUS_IS_SUCCESS(err));
/* assert(strcmp(this_entry.name, ".") == 0); This works */
err = apr_dir_read(&this_entry, APR_FINFO_NORM & ~APR_FINFO_IDENT, dir);
/* Problem 2: name contains "..." instead of ".." */
assert(strcmp(this_entry.name, "..") == 0);
apr_dir_close(dir); apr_pool_destroy(pool);
}
int main(int argc, char **argv) {
test("c:\\temp");
test("c:/temp");
return 0;
}
----- snip
1. Sometimes the apr translates the directory name into something
that some Win32 functions don't like.
Specifically if the directory given to apr_dir_open is given like
"d:/some/dir",
this gets translated inside apr into "\\?\d:\some\dir", a filename format
that GetNamedSecurityInfoW will not accept.
On the other hand, if the directory name is given like "d:\some\dir", the
translation will not take place, and the above mentioned function works.
2. There is a bug in apr\file_io\win32\dir.c (apr_dir_read). Subsequent
calls to this function will cause the internal variable wdirname to build up.
The first time wdirname contains d:\some\dir\.
Second time d:\some\dir\...
Third time d:\some\dir\...somefile.txt
The following patch fixes this problem
*** apr.orig/file_io/win32/dir.c Thu Apr 12 18:26:22 2001
--- apr/file_io/win32/dir.c Fri Jun 29 10:08:28 2001
***************
*** 222,227 ****
--- 222,228 ----
*/
#if APR_HAS_UNICODE_FS
if (os_level >= APR_WIN_NT) {
+ apr_status_t err;
/* Almost all our work is done. Tack on the wide file name
* to the end of the wdirname (already / delimited)
*/
***************
*** 228,234 ****
if (!eos)
eos = wcschr(wdirname, '\0');
wcscpy(eos, thedir->w.entry->cFileName);
! return more_finfo(finfo, wdirname, wanted, MORE_OF_WFSPEC,
os_leve
l);
}
else {
/* Don't waste stack space on a second buffer, the one we set
--- 229,237 ----
if (!eos)
eos = wcschr(wdirname, '\0');
wcscpy(eos, thedir->w.entry->cFileName);
! err = more_finfo(finfo, wdirname, wanted, MORE_OF_WFSPEC,
os_level
);
! eos[0] = '\0';
! return err;
}
else {
/* Don't waste stack space on a second buffer, the one we set
Sincerely
Mats Nilsson
Re: Report of incorrect behaviour of apr_dir_read on win32
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Thanks for your report! I'd fixed with a similar patch some time ago for the
growing dots problem, but the problem with GetNamedSecurityInfoW should now
be resolved as well.
Bill
----- Original Message -----
From: "Mats Nilsson" <ma...@xware.se>
To: <de...@apr.apache.org>
Sent: Monday, August 06, 2001 12:20 PM
Subject: Report of incorrect behaviour of apr_dir_read on win32
> Hi
>
> During my testing the subversion (http://subversion.tigris.org) on the
> Win32 platform, I ran into some problems with the apr_dir_open/apr_dir_read
> functions as implemented on Win32.
>
> The following is tested on a WinNT 4.0 sp6, using MSVC6 sp3.
> As for which version of APR I'm using, I can't really tell. However, I
> retrieved a APR CVS snapshot in april, and file_io/win32/dir.c has version
> 1.56.
>
> This test program demonstrate these problems:
>
> ----- snip
>
> #include "../apr/include/apr_pools.h"
> #include "../apr/include/apr_file_info.h"
>
> #include <assert.h>
>
> void test(const char *dirname) {
> apr_pool_t *pool; apr_pool_create(&pool, NULL);
> apr_dir_t *dir;
> apr_status_t err;
> apr_finfo_t this_entry;
>
> err = apr_dir_open(&dir, dirname, pool);
>
> /* Problem 1:
> * This call fails when dirname == "c:/temp", but not when it is "c:\\temp"
> */
> err = apr_dir_read(&this_entry, APR_FINFO_NORM & ~APR_FINFO_IDENT, dir);
> assert(APR_STATUS_IS_SUCCESS(err));
> /* assert(strcmp(this_entry.name, ".") == 0); This works */
>
> err = apr_dir_read(&this_entry, APR_FINFO_NORM & ~APR_FINFO_IDENT, dir);
>
> /* Problem 2: name contains "..." instead of ".." */
> assert(strcmp(this_entry.name, "..") == 0);
>
> apr_dir_close(dir); apr_pool_destroy(pool);
> }
>
>
> int main(int argc, char **argv) {
> test("c:\\temp");
> test("c:/temp");
> return 0;
> }
>
> ----- snip
>
> 1. Sometimes the apr translates the directory name into something
> that some Win32 functions don't like.
>
> Specifically if the directory given to apr_dir_open is given like
> "d:/some/dir",
> this gets translated inside apr into "\\?\d:\some\dir", a filename format
> that GetNamedSecurityInfoW will not accept.
>
> On the other hand, if the directory name is given like "d:\some\dir", the
> translation will not take place, and the above mentioned function works.
>
>
> 2. There is a bug in apr\file_io\win32\dir.c (apr_dir_read). Subsequent
> calls to this function will cause the internal variable wdirname to build up.
>
> The first time wdirname contains d:\some\dir\.
> Second time d:\some\dir\...
> Third time d:\some\dir\...somefile.txt
>
> The following patch fixes this problem
>
> *** apr.orig/file_io/win32/dir.c Thu Apr 12 18:26:22 2001
> --- apr/file_io/win32/dir.c Fri Jun 29 10:08:28 2001
> ***************
> *** 222,227 ****
> --- 222,228 ----
> */
> #if APR_HAS_UNICODE_FS
> if (os_level >= APR_WIN_NT) {
> + apr_status_t err;
> /* Almost all our work is done. Tack on the wide file name
> * to the end of the wdirname (already / delimited)
> */
> ***************
> *** 228,234 ****
> if (!eos)
> eos = wcschr(wdirname, '\0');
> wcscpy(eos, thedir->w.entry->cFileName);
> ! return more_finfo(finfo, wdirname, wanted, MORE_OF_WFSPEC,
> os_leve
> l);
> }
> else {
> /* Don't waste stack space on a second buffer, the one we set
> --- 229,237 ----
> if (!eos)
> eos = wcschr(wdirname, '\0');
> wcscpy(eos, thedir->w.entry->cFileName);
> ! err = more_finfo(finfo, wdirname, wanted, MORE_OF_WFSPEC,
> os_level
> );
> ! eos[0] = '\0';
> ! return err;
> }
> else {
> /* Don't waste stack space on a second buffer, the one we set
>
>
> Sincerely
>
> Mats Nilsson
>
>
Re: Report of incorrect behaviour of apr_dir_read on win32
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Mats Nilsson" <ma...@xware.se>
Sent: Monday, August 06, 2001 12:20 PM
> During my testing the subversion (http://subversion.tigris.org) on the
> Win32 platform, I ran into some problems with the apr_dir_open/apr_dir_read
> functions as implemented on Win32.
...>
> 1. Sometimes the apr translates the directory name into something
> that some Win32 functions don't like.
>
> Specifically if the directory given to apr_dir_open is given like
> "d:/some/dir",
> this gets translated inside apr into "\\?\d:\some\dir", a filename format
> that GetNamedSecurityInfoW will not accept.
>
> On the other hand, if the directory name is given like "d:\some\dir", the
> translation will not take place, and the above mentioned function works.
The other hand was actually a bug. That is fixed, as well. d:\some\dir will
now be parsed as \\?\d:\some\dir so it can be of (effectively) unlimited length.
Thanks for that catch too!
Bill