Fragile GnomeVFSXfer copying code - suggestions?

[Christian Neumair <chris gnome-de org>]

I've found the current Xfer code to be very fragile when copying, and
doing an overwrite.

When you move a directory, and force to overwrite an existing one, the
directory is removed before the move process begins, i.e. it is really
replaced.

When copying, the Xfer code however tries to merge the old directory
entries with the new ones, overwriting only conflicting ones.

The current code checks for conflicts using
gnome_vfs_directory_visit_uri (invoked from
handle_merged_directory_name_conflicts), which visits the directory
non-recursively (cf. gnome-vfs-directory.c:directory_visit_internal,
recursive is always FALSE). Whenever it encounters two directories, it
does not bail on conflict, the code obviously originally was meant to
merge the whole old with the whole new hierarchy recursively.

So when you had a directory like

/target/foo/bar

and copy from a directory like

/source/foo/bar

you won't be notified about "bar" conflicts. Later in the Xfer process
however, when processing foo/ in copy_directory, the inner
copy_directory will fail with GNOME_VFS_ERROR_FILE_EXISTS, which will be
chained up to the outer copy_directory call, which will pass the result
up to copy_items.
Now the process aborts and you will not be notified because the result
from gnome_vfs_xfer_uri_internal is discarded in
_gnome_vfs_xfer_private.

We have multiple ways to make the Xfer process in the copy case less
painful, apart from introducing HEAVILY NEEDED error handling:

a) Use the same overwrite semantics for copy as for move, i.e. when two
directories conflict, and an overwrite was demanded, just remove the
previous directory. This would mean that conflicts are only handled
(consistently!) non-recursively. In the example above, foo in target
would simple be rmdir'ed before the source directory is be copied over.
b) Write some code similar to handle_name_conflicts which handles
conflicts recursively, i.e. somehow invokes
handle_merged_directory_name_conflicts and does the same conflict check
that we do for the toplevel directory for the subdirectories before
doing its copy_ foo.
c) Make gnome_vfs_visit_uri work recursively. I don't have any expertise
in this area, and fear that I'll break something - some functions may
rely on its non-recursive semantics, maybe we need a RECURSIVE flag.

I personally prefer a), because it is the simplest implementation (we
can reuse move code), and because that's what I'd personally expect,
i.e. whether you pick copy or move should IMHO only be a flag for
"source files will still be in place after copy", and not for some
additional target merging voodoo.

Comments, suggestions?

-- 
Christian Neumair <chris gnome-de org>