From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artem Chuprina Newsgroups: gmane.emacs.bugs Subject: bug#16133: 24.3; copy-file fails on chmod when copying to FAT filesystem Date: Mon, 23 Dec 2013 00:13:36 +0400 Message-ID: <8738lkhcen.fsf@wizzle.ran.pp.ru> References: <52B62BC3.4050508@cs.ucla.edu> <83ob498s3q.fsf@gnu.org> <52B66414.1090709@cs.ucla.edu> <87y53czxz5.fsf@wizzle.ran.pp.ru> <52B7377C.3070004@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1387743256 8335 80.91.229.3 (22 Dec 2013 20:14:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 20:14:16 +0000 (UTC) Cc: 16133@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 22 21:14:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VupPn-0006cb-Nx for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Dec 2013 21:14:19 +0100 Original-Received: from localhost ([::1]:59149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VupPn-0001FQ-5k for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Dec 2013 15:14:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VupPd-0001Be-Mj for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:14:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VupPW-0000Zg-B8 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:14:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VupPW-0000Zc-6q for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VupPV-0007kA-Pb for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Artem Chuprina Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Dec 2013 20:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16133 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 16133-submit@debbugs.gnu.org id=B16133.138774323429742 (code B ref 16133); Sun, 22 Dec 2013 20:14:01 +0000 Original-Received: (at 16133) by debbugs.gnu.org; 22 Dec 2013 20:13:54 +0000 Original-Received: from localhost ([127.0.0.1]:34901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VupPN-0007jd-Mj for submit@debbugs.gnu.org; Sun, 22 Dec 2013 15:13:54 -0500 Original-Received: from minas.ran.pp.ru ([178.63.209.8]:39625) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VupPL-0007jU-9f for 16133@debbugs.gnu.org; Sun, 22 Dec 2013 15:13:52 -0500 Original-Received: from [188.32.7.67] (helo=wizzle.ran.pp.ru) by minas.ran.pp.ru with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VupPI-0001W2-GW; Sun, 22 Dec 2013 20:13:48 +0000 Original-Received: from ran by wizzle.ran.pp.ru with local (Exim 4.80) (envelope-from ) id 1VupP6-0001RR-Qw; Mon, 23 Dec 2013 00:13:36 +0400 In-Reply-To: <52B7377C.3070004@cs.ucla.edu> (Paul Eggert's message of "Sun, 22 Dec 2013 11:03:24 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82404 Archived-At: 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.