Joe Orton <joe@manyfish.co.uk> writes:
> > 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.
>
> 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?
Subversion itself has disbelieved the ordering promise in the past.
For example, see the following code in libsvn_subr/io.c (and similar
code in svn_io_remove_dir, and in svn_io_get_dirents, and in
libsvn_client/add.c:add_dir_recursive):
for (apr_err = apr_dir_read (&finfo, APR_FINFO_NAME, dir_handle);
apr_err == APR_SUCCESS;
apr_err = apr_dir_read (&finfo, APR_FINFO_NAME, dir_handle))
{
/* Ignore entries for this dir and its parent, robustly.
(APR promises that they'll come first, so technically
this guard could be moved outside the loop. But Ryan Bloom
says he doesn't believe it, and I believe him. */
if (! (finfo.name[0] == '.'
&& (finfo.name[1] == '\0'
|| (finfo.name[1] == '.' && finfo.name[2] == '\0'))))
{
retval = APR_ENOTEMPTY;
break;
}
}
(That's been there since r2404. Oooh, and I just noticed it's missing
a paren in the comment :-). )
Anyway, regardless of whether the documented ordering is eventually
enforced by APR, we have a serious bug right now: 'svnadmin hotcopy'
is our primary backup story, and ext3 with a 2.6 Linux kernel isn't so
uncommon these days.
Is there any way of invoking hotcopy so that it doesn't stimulate this
problem (i.e., can we document a workaround)? If not, is there some
other non-klugey backup method we can offer people on ext3/2.6?
Obviously, we can fix this internally in 1.0.1, I'm just concerned
about 1.0.0...
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 17 17:24:50 2004