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 <[EMAIL PROTECTED]> _______________________________________________ gnome-vfs-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-vfs-list
