When copying large files and an error occurs it is very difficult to tell what
files had problems and whether the problem was on the source or destination of
the copy operation.  In addition, the filename is ellipsized (as addressed also
in Bug 152026 and 313951), making it impossible to tell on which files the
operation failed.  Unlike 152026, which addresses move operations, on a copy
operation it is not possible to see what files failed strictly by examining the
files that remain in the source directory.  Instead, the user needs to go to the
command problem and do some scripting to check to see what files are missing. 
This is really suboptimal.

Here are three concrete improvements to fix this issues:

1. Don't ellipsize filenames or make it so that when a filename does become
ellipsized it is possible to expand the dialog to see the whole filename, or
paste it from the clipboard or something.

2. Make it clear on a copy operation whether or not it was a problem with
reading the source file or writing the destination file.  In my case I was
copying files over a network and was told "access denied" but only given the URL
for the source, indicating to me that it was a problem with reading the file,
when in fact it was a problem with writing the file on the remote host.

3. Make a distinction between files and directories in the dialog.  When the
name is ellipsized, just knowing if it's a file or a directory helps out a lot.

While very similar the 152026, the "workaround" (which really is do it yourself
from the shell) is a bit more complex than many desktop users are capable of.

Other information:
I've made a screenshot of the error dialog at
http://patrick.wagstrom.net/resources/images/blog/uselessErrorMessages.png