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. -- Christian Neumair <chris gnome-de org>
Attachment:
signature.asc
Description: This is a digitally signed message part