[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: dot, dot-dot and apr_dir_read

From: Joe Orton <joe_at_manyfish.co.uk>
Date: 2004-02-17 13:30:58 CET

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?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 17 13:31:19 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.