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
