bug#16133: 24.3; copy-file fails on chmod when copying to FAT filesystem

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
> A library function should
> never decide on its own when to call it quits

Copy-file signals errors in many circumstances;
this is just one of them.  If the goal is to have
a library function that does not "decide on its
own when to call it quits", then the function should
return a value indicating the error, rather than
throwing an exception.  That might be too much of
a change to copy-file, but we could have a variant
of copy-file that does that, suitable for library
use.

> It is only justified to do that when the
> error is fatal; this one isn't: the file was copied.

The contents of the file were copied, but the permissions
were not.  The specification of copy-file says that it
copies both contents and permissions.

I would favor changing the specification of copy-file,
so that it doesn't copy the permissions
unless its 6th argument is non-nil.  We could change
the name of the 6th argument to PRESERVE-PERMISSIONS.
The 6th argument already governs how permissions are
preserved, so this would be a reasonable change.  I don't
think it'd hurt existing applications, since the default
permissions when creating a file would be the same as
it is now -- the only change would be that copy-file
wouldn't attempt to change the permissions of an already-existing
file unless PRESERVE-PERMISSIONS is non-nil.