> Being "smart" about how file transfers like that are done isn't really a > good idea. For instance, the target could be a svn webdav repo, or > something else where the file operations don't behave the way you > expect. I think the best solution to this would be to have the operation > not be undoable (and say so in the conflicts dialog). Ideally the undo > command would be greyed out in the ui, less ideal it would give an error > dialog on undo. Greying out the undo in the menu is not always a good idea: if the implementation supports multi-level undos, performing an "undoable" operations will in fact make "undoable" all other previous operations. > Well, that is a benign problem. What if you're undoing a move of a file > from a to b, and during the time something wrote a newer version of the > file at a. The undo will then cause a loss of data (overwriting the > newer file with the older version). A similar problem exists also for "non-undo-related" operations. > Yeah. But we have to be totally anal about this. We should verify all > pre-requirements like there being no file in a place we don't expect it > to be before starting, and we should handle errors *very* carefully and > warn on any problem. I think people have some expectations that there > can be a problem on an i/o operation like a copy, but not as much when > it comes to "undo", because its an operation that can never fail in all > other applications. > > Even if we're mega careful we're gonna have issues where the undo > command failed in the middle of the operation (due to some i/o error, > like disk full, write error, races with another app writing to the same > dir, etc) and we will then end up in some quite weird state. I'm looking at other file manager to see if and how they deal with these issues. I've put a wiki page at http://live.gnome.org/Nautilus/Undo to discuss "how the undo should behave". -- Amos Brocco | Ph.D Student | Computer Science Department - DIUF | University of Fribourg | A406 Pérolles 21 | Bd. Pérolles 90 | CH-1700 Fribourg | http://diuf.unifr.ch/pai/people/broccoa
Attachment:
signature.asc
Description: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente