Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 92720 invoked from network); 17 Feb 2004 12:31:05 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 17 Feb 2004 12:31:05 -0000 Received: (qmail 75322 invoked by uid 500); 17 Feb 2004 12:31:02 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 75261 invoked by uid 500); 17 Feb 2004 12:31:02 -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 75170 invoked from network); 17 Feb 2004 12:31:01 -0000 Date: Tue, 17 Feb 2004 12:30:58 +0000 From: Joe Orton To: dev@subversion.tigris.org, dev@apr.apache.org Cc: rbb@rkbloom.net Subject: Re: dot, dot-dot and apr_dir_read Message-ID: <20040217123058.GB22240@manyfish.co.uk> Mail-Followup-To: dev@subversion.tigris.org, dev@apr.apache.org, rbb@rkbloom.net References: <1076980391.40316aa74be8c@webmail.mydomain.com> <873c9a5tmq.fsf@codematters.co.uk> <20040217093008.GM21663@occipital.brain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20040217093008.GM21663@occipital.brain.org> User-Agent: Mutt/1.4.1i X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Tue, Feb 17, 2004 at 01:30:08AM -0800, Ben Reser wrote: > On Tue, Feb 17, 2004 at 02:26:05AM +0000, Philip Martin wrote: > > Thanks, that will solve our problem long term. I wonder what we > > should do for Subversion 1.0? Ship with a big disclaimer that hotcopy > > does not work on ext3? Implement our own dot-first stuff in > > svn_io_dir_walk? Wait for an APR fix and require that version? I've > > had a look at the Subversion code and I think hotcopy is the only > > thing affected. > > I think that's the best thing to do. We've already got a similar caveat > issue with libsvn_diff, linux (and some other OSes), 32-bit archs, and > the perl bindings. There's a fix for it in apr's CVS tree. > > In the case of upstream bugs that we know will be fixed I think this is > the logical thing to do. Applying ugly hacks to work around problems > that are going to go away just isn't appealing. :) Well... since POSIX does not require a "." and ".." dir entry, should APR return them from apr_dir_read() anyway, and lie to the app for such weird directories? I'm not convinced that the API-guarantee-which-isn't shouldn't just be removed. MSDN says FindNextFile doesn't guarantee ordering either, fixing this with the same logic N times in APR isn't particularly attractive. I'd guess that most apps will either not care about ordering or sort the list anyway? Regards, joe