[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: <kfogel_at_collab.net>
Date: 2004-02-17 16:22:22 CET

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
  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;

(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...


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

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.