Re: [PATCH] Improve Nautilus XFer code

[Alexander Larsson <alexl redhat com>]

On Tue, 2006-01-10 at 21:38 +0100, Christian Neumair wrote:
> Nautilus used to handle all the error handling in its asynchronous
> gnome_vfs_async_xfer callback, but it is not guaranteed to be always
> called, so problems may remain unhandled and cause data loss ([1]).
> [2] has some details.

I'm not sure why you think the asynchronous callback isn't always called
in the error cases.

The sync callback is called for every state change, including every
single file operation to tell you what happens. Its called "sync"
because you're not supposed to do slow, blocking (ui) operations in it.
Nautilus uses this primary to collect the exact uris for new and changed
files to update its ui.

The async callback is used for slower, ui handling. Its where you handle
errors, and progress updates. Its *always* called on errors or other
"must be handled by user" cases (name conflicts, etc), but its only
periodically called when it comes to "normal" progress so that you can
update a progress bar without slowing down the app to a crawl.

This is even (badly) documented:
 * @progress_update_callback: called when the program requires responses
 * to interactive queries(e.g. overwriting files, handling errors, etc).
 * @progress_sync_callback: called periodically to keep the client
 * appraised of progress in completing the xfer operation, and the
 * current phase of the operation.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a jaded one-eyed assassin from the Mississippi delta. She's a hard-bitten 
Buddhist queen of the dead prone to fits of savage, blood-crazed rage. They 
fight crime!