Re: Nautilus Undo

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-10-26 at 19:58 +0200, Amos Brocco wrote:
> Il giorno ven, 26/10/2007 alle 15.50 +0200, Alexander Larsson ha
> scritto: 
> > 
> > If I copy a file over another file. How do you undo that?
> 
> In the actual implementation, the undo just deletes the file; afaik this
> is the same behavior found in Windows, so it would be far from an
> unexpected behavior for most of the users.
> As a side note, I've observed that KDE Dolphin proposes either to rename
> the file or to overwrite the existing copy. In the first case, the undo
> even deletes the wrong file (the file with the original name, and not
> the renamed copy!), in the latter case, the copy is deleted.
> 
> An improvement would consist in Moving to trash the existing file
> instead of deleting it, so that the following undo sequence would
> restore the original file: 1. Undo Copy (delete the copied items), 2.
> Undo move to trash (restore the replaced item from trash).

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.

> > If I copy a directory and the copied files are merged into an existing
> > directory, can it undo that?
> 
> In the actual implementation undoing will result in the whole folder to
> be deleted (same behavior as in KDE Dolphin); for two reasons:
> 1. only the uri of the directory is stored as undo information. 
> 2. when there is a conflict, if the user chooses "Replace",
> GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL that
> hides everything, we don't know which file is actually overwritten.
> 
> Solutions:
> 1. store a complete list of the directory contents (source uris, target
> uris)
> 2. Avoid using GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL in order to
> know exactly which file is replaced.
> 
> Another (easier and safer) solution would be to disable undo (and inform
> the user about that) if the file operation involves replacing files
> (this is the approach taken by Windows Explorer), even if the user
> choses to skip overwriting.

Again, I think the best approach here is to just admit that this is to
hard and say that you can't undo an operation like that.

For the gnome_vfs_xfer issues, I think we're in a better spot with the
gio-branch of nautilus. gio doesn't have an equivalent operation to
xfer. The most highlevel operations it has is "copy single file" (which
fails on directories with G_IO_ERROR_WOULD_RECURSE). This means
a) We get rid of the crappy gnome_vfs_xfer API
b) We have to reimplement something like xfer inside nautilus

It might not be obvious that b) is a good thing, but it really is. There
just is no way to make a generic API for this kind of thing which
supports a nice full UI. But the nautilus version doesn't have to be
generic in that sense, when it gets an error it can just create the
dialog it wants and display int, instead of passing the error through
some generic gnome-vfs-xfer state change callback. 

It also means we can much make nicer dialogs in cases like overwriting a
file where we can display icon, thumnbnail, dates, sizes, etc in the "do
you want to overwrite this file with this" dialog.

> > What happens if you try to undo something, and a process external to 
> > nautilus has modified the filesystem since the operation nautilus is to
> > undo. (For instance, removed the file you're moving back.)
> 
> Nothing, the action does nothing (no error is shown)... same behavior as
> KDE Dolphin.

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).

> > And in general, is it a good idea to expose an undo system in the UI
> > when its gonna have so many cases like this when it doesn't work? Users
> > might rely on it and then loose data when undo unexpectedly doesn't
> > work.
> 
> The best we can do is to inform the user what 
> the undo really does or doesn't (or can do or can't), and at least avoid
> that undo/redo destroy data without the user knowing about it.

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.