Re: Patch to fix #314139 [REVISION PROPOSAL]

[Alexander Larsson <alexl redhat com>]

On Wed, 2006-06-07 at 21:39 +0300, Sivan Greenberg wrote:
> Hi Again, the wonderful users and hacker of nautilus.
> 
> I would like to bring your attention again to a patch I have created
> originally using pure gnome_vfs functions to check if the source's
> parent is read only, and if so default to a copy operation instead of a
> move operation which previously caused hassle, confusing and much mess
> among especially converts from other operating system, as to why "Such a
> trivial operation needs to involve hassle and why do I even need to
> think about it and select copy from the context menu??" etc.. ;-)
> 
> So after realizing this patch is not good enough, due to it being inside
> a callback which gets called multiple times per each DND operation,
> Manny on the irc channel proposed I use instead of the native gnome-vfs
> methods, the nautilus infras. for file manipulation (to check if the
> source uri's parent is read only) , namely
> libnautilus-private/nautilus-file.h::nautilus_file_get_existing
> 
> and
> 
> libnautilus-private/nautilus-file.h::nautilus_file_peek_vfs_file_info
> 
> Now my question is, should I get a new patch in the same a approach of
> the previous one (which actually followed another patch approach, from
> the file ownership bug) but with the this time cache enabled functions
> of nautilus-file.h, will this be accepted by the upstream maintainers?
> 
> I would hate to start work on it, just to realize I need to re-do it
> again.
> 
> Many thanks, and apologies for the spam :)

This is tricky stuff. In general we try to avoid sync i/o in Nautilus,
but its very complicated to do in the case of dnd where we really need a
sync reply immediately or the ui looks weird (we don't immediately show
the right cursor and you might have to wiggle the mouse to get it to
change even).

Another complication is that doing generic gnome-vfs i/o can cause
authentication dialogs to pop up, which is bad during dnd.

So, I think the best workaround is to continue using sync i/o in this
case. But lets try minimizing it. So, only do this magic for local files
(i.e. file: uris), stat as few times as possible and cache i/o results.

So, the two patches in your mail need to be combined into one
should_convert_move_to_copy() function that does at most one stat of the
target and one of the source. Furthermore, we should cache the results
of this function for the last target/source pair, which I think can be
done by using user-data on the drag context.

Does that sound good?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a leather-clad sweet-toothed dwarf gone bad. She's a wealthy hip-hop 
hooker living homeless in New York's sewers. They fight crime!