apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: cvs commit: apr/test testfile.c
Date Sun, 29 Dec 2002 21:20:21 GMT

We need to decide how we are going to handle this test.  The only way to
test for this condition on Unix is to do a stat in apr_file_info.  That
seems like an incredibly heavy-weight solution.

The problem is that Windows can't open a directory with CreateFile, which
is the API that we use under the covers in apr_file_open.

Does anybody know of a light-weight solution for Unix or an API that can
open both files and directories on Windows?

Ryan

On 29 Dec 2002 wrowe@apache.org wrote:

> wrowe       2002/12/29 11:51:34
>
>   Modified:    test     testfile.c
>   Log:
>     apr_file_open(f, "directory", ..., p) is not portable, test for it.
>
>   Revision  Changes    Path
>   1.64      +22 -18    apr/test/testfile.c
>
>   Index: testfile.c
>   ===================================================================
>   RCS file: /home/cvs/apr/test/testfile.c,v
>   retrieving revision 1.63
>   retrieving revision 1.64
>   diff -u -r1.63 -r1.64
>   --- testfile.c	29 Dec 2002 19:41:20 -0000	1.63
>   +++ testfile.c	29 Dec 2002 19:51:34 -0000	1.64
>   @@ -61,7 +61,8 @@
>    #include "apr_lib.h"
>    #include "test_apr.h"
>
>   -#define FILENAME "data/file_datafile.txt"
>   +#define DIRNAME "data"
>   +#define FILENAME DIRNAME "/file_datafile.txt"
>    #define TESTSTR  "This is the file data file."
>
>    #define TESTREAD_BLKSIZE 1024
>   @@ -79,14 +80,26 @@
>                           APR_UREAD | APR_UWRITE | APR_GREAD, p);
>        CuAssertTrue(tc, rv != APR_SUCCESS);
>        CuAssertIntEquals(tc, 1, APR_STATUS_IS_EACCES(rv));
>   -#if 0
>   -    /* I consider this a bug, if we are going to return an error, we shouldn't
>   -     * allocate the file pointer.  But, this would make us fail the text, so
>   -     * I am commenting it out for now.
>   -     */
>        CuAssertPtrEquals(tc, NULL, thefile);
>   -#endif
>   -    apr_file_close(thefile);
>   +    if (thefile) {
>   +        apr_file_close(thefile);
>   +    }
>   +}
>   +
>   +static void test_open_dir_read(CuTest *tc)
>   +{
>   +    apr_status_t rv;
>   +    apr_file_t *thedir = NULL;
>   +
>   +    rv = apr_file_open(&thedir, DIRNAME,
>   +                       APR_READ,
>   +                       APR_UREAD | APR_UWRITE | APR_GREAD, p);
>   +    CuAssertTrue(tc, rv != APR_SUCCESS);
>   +    CuAssertIntEquals(tc, 1, APR_STATUS_IS_EACCES(rv));
>   +    CuAssertPtrEquals(tc, NULL, thedir);
>   +    if (thedir) {
>   +        apr_file_close(thedir);
>   +    }
>    }
>
>    static void test_open_excl(CuTest *tc)
>   @@ -99,17 +112,7 @@
>                           APR_UREAD | APR_UWRITE | APR_GREAD, p);
>        CuAssertTrue(tc, rv != APR_SUCCESS);
>        CuAssertIntEquals(tc, 1, APR_STATUS_IS_EEXIST(rv));
>   -#if 0
>   -    /* I consider this a bug, if we are going to return an error, we shouldn't
>   -     * allocate the file pointer.  But, this would make us fail the text, so
>   -     * I am commenting it out for now.
>   -     */
>        CuAssertPtrEquals(tc, NULL, thefile);
>   -#endif
>   -    /* And this too is a bug... Win32 (correctly) does not allocate
>   -     * an apr_file_t, and (correctly) returns NULL.  Closing objects
>   -     * that failed to open is invalid.  Apparently someone is doing so.
>   -     */
>        if (thefile) {
>            apr_file_close(thefile);
>        }
>   @@ -526,6 +529,7 @@
>        CuSuite *suite = CuSuiteNew("File I/O");
>
>        SUITE_ADD_TEST(suite, test_open_noreadwrite);
>   +    SUITE_ADD_TEST(suite, test_open_dir_read);
>        SUITE_ADD_TEST(suite, test_open_excl);
>        SUITE_ADD_TEST(suite, test_open_read);
>        SUITE_ADD_TEST(suite, test_open_readwrite);
>
>
>
>



Mime
View raw message