Re: [RFC] [PATCH] Fix copying/moving of metadata where source/dest metafile are not yet read

[Alexander Larsson <alexl redhat com>]

On Mon, 2005-09-26 at 17:17 +0200, Christian Neumair wrote:
> Am Montag, den 26.09.2005, 12:16 +0200 schrieb Alexander Larsson:
> > On Mon, 2005-09-19 at 16:42 +0200, Christian Neumair wrote:
> > > The attached patch tries to fix moving/copying of metadata if the source
> > > or destination metafile are not yet read. I'd like to get some feedback
> > > whether the overall architecture/resolution proposal looks sane. Maybe
> > > people familiar with async APIs do see some shortcomings/issues?
> > 
> > I had a quick look, and it seems sane. I worry a bit about ordering
> > though. What if someone first removes info for a file and then copies
> > some new info to it. The way this is resolved atm is by:
> > +
> > +	nautilus_metadata_process_ready_copies ();
> > +	nautilus_metadata_process_ready_removals ();
> > 
> > I.E. The copy will be done before the removal (if the source of the copy
> > is read), and the result will be that the newly copied info will be
> > removed. Maybe the two pending lists should be merged?
> > 
> > Even with a merged list there could be problems, e.g. in the example
> > above if the source of the copy was read after the target. I'm not sure
> > there is a way around this except with full-blown dependency tracking,
> > which seems a bit heavy. Could you ponder over the possibilities here?
> 
> My first idea was also that it is worth to be aware of pending removals
> when copying.
> 
> The final conclusion was that if the user changes a directory hierarchy
> that is currently involved into a file operation, there is no way to
> know whether he wants to apply his changes only to the source tree, or
> also to the file operation destination.

I think thats a slightly different thing though. I mean, for instance if
you remove a file, and then copy a new file into that space. Its pretty
obvious that you don't want the newly copied metadata to be removed.
Yet, this can happen if the reading of the metadata file for the
directory where the initial file was removed wasn't read, and the copy
is done immediately after the remove.

This would mostly be a problem on slow filesystems i guess, and since
metadata is stored in the homedir this might not be a huge problem in
practise. I mean, its clearly better than what we do now.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a suave dishevelled grifter plagued by the memory of his family's brutal 
murder. She's a strong-willed gold-digging single mother from a different time 
and place. They fight crime!