[lug] File replace thought

[Sean Reifschneider]

On Tue, Sep 18, 2007 at 04:31:40PM -0600, Lori Reed wrote:
>I really don't think you'd want this, since it more than doubles the 
>execution time to copy a file.

It doesn't double the execution time, it decreases it at worst.  If it's
implemented right.

Workflow without diff option, where diff is wanted:
   Drag and drop file to new location.
   Dialog comes up that says "Do you want to overwrite file?  yes/no?"
   User brings up a shell window.
   Find the directory locations.
   Construct and run diff command manually.
   Review contents and make decision.

Steps 3, 4, and 5 may be computationally cheap but are human expensive and
could easily dominate overall execution time.

Workflow with diff option, where diff is wanted:
   Drag and drop file to new location.
   Dialog comes up that says "Do you want to overwrite file?  yes/no/(diff)?"
   Click on "diff" button.
   Review contents and make decision.

If the user doesn't want a diff, both paths are the same.  If they do, the
latter saves the user dramatic amounts of time.

Now all we need is a uber diff program that shows smart diffs.  Images?
Show me both thumbnails with the option to see the full size or possibly
overlay them.  Source code, show me a context diff.  Tar files, examine the
contents...

Now, if you really wanted to be clever:
   Drag and drop file to new location.
   Dialog comes up that says "Do you want to overwrite file?  yes/no/(diff)?"
   In the background when the dialog comes up:
      Start a throbber in the dialog.
      Start running a checksum or "how different are they" program.
      If the user clicks a choice, terminate background comparison.
      Otherwise, display difference information in place of throbber.

If the comparison takes longer than it takes the user to choose, then the
comparison is free.  Of course, if the compare compares files that fit in
the buffer cache, we've now sped up the copy operation after the user makes
their decision.

So, if your objection is simply one of increasing execution time, we're
probably not any worse off in any case.  Certainly not from a human "cost
of operation" standpoint.  In fact, this mechanism is much less expensive
in human time, worst case it's the same (user decides not to do a diff).

Of course, worrying about execution time in a user-interactive system is
often the wrong thing to optimize for.  A user environment should often
spend computer resources to save human resources.

I mean, this is the whole reason for the desktop environments.  For people
who don't know what they're doing, the menus will save them from having
to spend considerable time tracking down what they want.  I remember when I
was first learning Unix I spent a lot of time just reading section 1 of the
man pages.  In fact, I read all of the man sections for HP-UX, back when
that was around 700 to 1000 pages.  It let me be really efficient because I
didn't have to hunt around menus to find various things I wanted to do, but
it burned a LOT of my time getting there.

For casual computer users, the investment in learning the CLI may never pay
off.  I know that I do fancy document creation and typesetting sorts of
tasks so infrequently that I need the GUI there.  Having to know the
wordstar commands for doing everything would suck the couple of times a
year when I decide I have to do something like that.

It really boils down to this: At the moment a user copies a file over
another file, "How are they different" is a question they are likely to
want to be able to answer.  I could also imagine that, instead of "yes" and
"no" you might want options like:

   Backup -- Rename the destination file to a ".bak" name, and then copy
   the file.

   Snapshot -- If you're running on ZFS or something, go ahead and take a
   file-system snapshot and then do the copy.

   Commit -- If I'm in a version-control repository, check in the current
   version if it's different, then do the copy.

That would be a kick ass file copy confirmation dialog.

In fact, this ties into something I was thinking of the other day.

It would be nice to have a file-system journal that users could interact
with retrospectively.  Oh crap, I copied all these files into the wrong
directory.  Now I have to spend time going through and pulling the files
back out and putting them in the real directory I wanted, without
disturbing the files that were previously there.  Hopefully, I didn't
overwrite some files with the same name in both directories.

It would be very cool to be able to look at a journal of changes on the
file-system, click on a bunch of them and either pull out the list of file
names that were copied, or just revert that whole set of changes.
Something like this could be implemented with inotify, at a user level.
Though it couldn't deal with overwritten files, it could at least alert you
of what you needed to pull from backups.

Sean
-- 
 I'd like an order of fries, a quarter-pounder with cheese,
 I love the light in your eyes, will you go out with me please.
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability