dot, dot-dot and apr_dir_read

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231364 is a Debian
bug report of an "svnadmin hotcopy" that fails because it appears to
try to create a file before the parent directory exists.

The bug report prompted me to look at the hotcopy code and I see that
it uses svn_io_dir_walk and that it relies on a callback for "." being
made before any callbacks for files or subdirectories. The
svn_io_dir_walk documentation doesn't mention any ordering, so the
hotcopy code has a problem.

Now svn_io_dir_walk uses apr_dir_read which documents it's behaviour
as

 "All systems return . and .. as the first two files."

so that looks OK, we can use this guarantee to document the behaviour
of svn_io_dir_walk. Unfortunately, that's not the end of the story.

Being curious I looked at the Unix implementation of apr_dir_read to
see how this ordering was implemented, and as far as I can see the
ordering is not guaranteed. APR uses readdir, or readdir_r, neither
of which provide the required guarantee. For example, POSIX states
that entries for dot and dot-dot will be returned if they exist but
does not specify any ordering. Lots of systems do appear to provide
the "dot-first" ordering, but I believe it is filesystem dependent. A
Google search came up with http://perlmonks.thepen.com/112867.html
which reports that readdir on XFS isn't always "dot-first".

Questions for APR:

 - Is the documented "dot-first" behaviour of apr_dir_read intended?
 - If it is, how does the current implementation of apr_dir_read
   guarantee it?

Questions for Subversion:

 - Is svn_io_dir_walk supposed to be "dot-first"?
 - If it is, are we going to rely on APR to provide it or implement it
   locally?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org