Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 12231 invoked by uid 500); 2 Jul 2002 20:17:56 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 12220 invoked from network); 2 Jul 2002 20:17:56 -0000 To: "Ryan Bloom" Cc: , Subject: Re: proposal to add apr_check_dir_empty() to APR References: <010301c22204$2a852e60$c000000a@KOJ> Reply-To: kfogel@collab.net X-Windows: don't get frustrated without it. From: Karl Fogel Date: 02 Jul 2002 15:08:58 -0500 In-Reply-To: <010301c22204$2a852e60$c000000a@KOJ> Message-ID: <853cv1x57p.fsf@newton.ch.collab.net> Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1.50 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Ryan Bloom" writes: > This isn't portable. POSIX specifically states that you don't need to > return "." or "..", and APR doesn't make any comments about them. Actually, APR does promise that "." and ".." will be returned, and will be returned first, on all platforms. See apr/include/apr_file_info.h: /** * Read the next entry from the specified directory. * @param finfo the file info structure and filled in by apr_dir_read * @param wanted The desired apr_finfo_t fields, as a bit flag of \ APR_FINFO_ values * @param thedir the directory descriptor returned from apr_dir_open * @remark All systems return . and .. as the first two files. */ APR_DECLARE(apr_status_t) apr_dir_read(apr_finfo_t *finfo, > The return code should not be EGENERAL if the directory isn't empty. > Create a new status code if you have to, but a non-empty directory is > not an error condition. Agreed, can make up a better status code for this. > If you fix those two problems, then I am all for this going into APR. > However, can we get better performance on some platforms by using native > functions??? I don't know. Anyone know? -K