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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 22 Dec 2013 09:37:26 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 16133@debbugs.gnu.org, ran@lasgalen.net
> 
> Eli Zaretskii wrote:
> > I was referring to the use case described here:
> > 
> >   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16133#14
> > 
> > The 'cp' equivalent of that is when it is invoked to copy more than
> > one file, or copy a directory.
> 
> The use case described there does not involve merely copy-file;
> it also involves some other function (org-mobile-push, I guess)
> that uses copy-file to copy files one at a time,
> and which gives up if one instance of copy-file fails.
> 
> This is akin to a shell script that uses cp to
> copy files one a time, and which aborts if cp fails.
> Such a script would behave the same way that org-mobile-push
> behaves now, if I'm understanding the bug report correctly.
> 
> One fix would be to modify org-mobile-push to not throw an error
> when copy-file fails, but instead to continue.  Perhaps this is the
> desired behavior, not only for fchmod failure, but for other copy-file
> failures such as write error.  In any case org-mobile-push could 
> ignore some or all errors, or report them at the end, or whatever
> it likes.

Sorry, I disagree: it is not the business of copy-file to decide when
to interrupt its caller.  It is only justified to do that when the
error is fatal; this one isn't: the file was copied.

copy-file is akin to a library function.  A library function should
never decide on its own when to call it quits, because a library
function never has enough context to do TRT.