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

[Artem Chuprina <ran@lasgalen.net>]

Paul Eggert -> Artem Chuprina  @ Sun, 22 Dec 2013 11:03:24 -0800:

 >> With copy-file in emacs24 I just cannot write such code

 PE> It's certainly *possible* to write such code: just catch
 PE> the error and continue.

Not.  It's possible to write code that does the same, but it would be
MUCH more code.  Just to fight bad default behavior.  It's like instead of

#!/bin/sh -e
cp ....

you should EVER write

#!/bin/sh -e
cp ... || rc=$?
case $rc in
5,7,13,17) ;; # ignore chown, chmod, chattr and like problems
*) exit $rc
esac

Almost nobody almost never wants this.  

 >> much code that used copy-file before, just stopped working.  (I've
 >> mentioned org-mobile-push, and emacs' own file backup code

 PE> This is a more serious matter, but it's a judgment call as to
 PE> whether it stopped working or started working.  Some users
 PE> want permissions to be saved, as well as contents.  Others
 PE> don't.  Emacs should support both usages.

I've seen insisting on chown/chmod success when copying in ONE task
only: rsync backup of the WHOLE system.  I've never seen somebody who
will try to use emacs' copy-file for that task.

I think that if you want Emacs to support such a strange behavior, it
would be OK.  But NOT as default behavior.  As you appeal to GNU cp, see
its default behavior: BY DEFAULT it TRIES to save permissions and
owner/group, but DOES NOT fail if cannot.  If you personally insist that
this should be failure, cp allows this to you, but you must express this
EXPLICITLY.

I'm sure that copy-file should behave in this style.

 PE> I'm still puzzled as to why you're observing the problem and
 PE> I am not.  Can you do an 'strace' on an Emacs that's exhibiting
 PE> the problem?  It'd be helpful to see exactly which system calls
 PE> are being invoked, and the errno value for the failing one.
 PE> Possibly there is a small workaround here that wouldn't require
 PE> redesining copy-file.

$ touch testfile
$ strace -otrace emacs24 -Q
M-: (copy-file "testfile" "c1/testfile")
Debugger entered--Lisp error: (file-error "Doing chmod" "operation not permitted" $
  copy-file("testfile" "c1/testfile")
  eval((copy-file "testfile" "c1/testfile") nil)
  eval-expression((copy-file "testfile" "c1/testfile") nil)
  call-interactively(eval-expression nil nil)
C-x C-c

Relevant part of trace:
stat64("/home/ran/c1/testfile", 0xbeb0ff38) = -1 ENOENT (No such file or directory)
lstat64("/home/ran/c1/testfile", 0xbeb0ff20) = -1 ENOENT (No such file or directory)
open("/home/ran/testfile", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("/home/ran/c1/testfile", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0644) = 5
read(4, "", 16384)                      = 0
fchmod(5, 0644)                         = -1 EPERM (Operation not permitted)
stat64("/usr/share/emacs/24.3/lisp/debug.elc", 0xbeb0fbe8) = -1 ENOENT (No such file or directory)
... (search for debugger)
stat64("/usr/share/emacs/24.3/lisp/emacs-lisp/debug.elc", {st_mode=S_IFREG|0644, st_size=27568, ...}) = 0
open("/usr/share/emacs/24.3/lisp/emacs-lisp/debug.elc", O_RDONLY|O_LARGEFILE) = 6

Indeed, after your request, I've tried to reproduce the bug on my
netbook, and for the first time could not.  Then I thought a little
more, and mounted FAT partition with options similar to those on Android
in question, that is,

mount -o fmask=0700,dmask=0700 /dev/sda1 /fat

(on Android they are exactly rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

The problem reproduced.  

Further investigation shows that with (very reasonable on a multi-user
Linux system) mount options for VFAT

mount -o fmask=0111,dmask=0 /dev/sda1 /fat

(that is, all files belong to root:root, files have permissions 0666,
directories - 0777) we have the same problem.

That is, relevant part is that the resulting file does not belong to me
but I can write to it, I can create files there, but I cannot change
their metainfo, because they are not mine.  On Android I can write
through group permissions, in this case - through other permissions,
effect is the same.

If filesystem belongs to me, fchmod silently succeeds (permissions don't
change, of cause).  The problem also not reproduced if filesystem is
mounted with quiet option (it is designed just for this).  It is also
very reasonable on Linux systems when mounting FAT, but Android does not
use this option when mounting SD cards.