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
