apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Nilsson <mats.nils...@xware.se>
Subject Report of incorrect behaviour of apr_dir_read on win32
Date Mon, 06 Aug 2001 17:20:29 GMT
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


Mime
View raw message