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

[Artem Chuprina]

Paul Eggert -> Eli Zaretskii  @ Sun, 22 Dec 2013 10:54:48 -0800:

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

I'd prefer copy-file behavior just like cp's.  That is, ever try to
preserve permissions, owner, ACLs etc, but by default throw an error
only if file CONTENT is not copied successfully.  Metainformation copy
failures should throw error on explicit request.  Probably, it would be
reasonable to have not several parameters, but one parameters
THROW-ERROR-ON(-META) with a list of flags, like '(acl owner times), t
for all, nil (default) for none.  Also like cp, it should NOT try to
copy times by default, only on explicit request.  But also, request to
copy times in NOT yet a reason to throw error.

For backward compatibility, it has sense to keep PRESERVE-UID-GID, but
also for backward compatibility, with BACKWARD-COMPATIBLE behavior (that
is, NOT throw an exception, AGGRHH!).  If we don't bother backward
compatibility, it would be better to remove PRESERVE-UID-GID entirely,
replacing it with THROW-ERROR-ON.