189627 2007-08-20 18:43 0000 app-editors/emacs-22.1 hangs while saving if it lacks permission to remove backup 2007-08-24 07:35:02 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified All Linux RESOLVED FIXED http://groups.google.com/group/gnu.emacs.bug/browse_frm/thread/ac86a7a206dbcd94/ REGRESSION P2 normal --- 1 Martin.vGagern@gmx.net emacs@gentoo.org Martin.vGagern@gmx.net 2007-08-20 18:43:40 0000 When emacs can't remove a backup file (FILE~) for a file it wants to write, it will go into a loop. C-g gets it out of the loop, but I found no way to get the modified file actually written. This is especially annoing if you are editing in a foreign directory with only very specific access permissions. Reproducible: Always Steps to Reproduce: 1. mkdir emacs-bug 2. cd emacs-bug 3. echo foo > foo.txt 4. echo bar > foo.txt~ 5. chmod u-w . foo.txt~ 6. emacs foo.txt 7. Change contents from "foo" to "baz" 8. C-x C-s to save Actual Results: Displays clock cursor, will stay like that until you abort the command pressing C-g. strace reports lots of stat and unlink kalls for "foo.txt~". The file contents still reads "foo". Expected Results: Modifications to file foo.txt saved, probably some warning about the outdated backup, as you will get a warning if emacs fails to create a new backup in case there was none before. gentooperson@yahoo.com 2007-08-20 19:02:54 0000 I reproduced this. Promote upstream. This isn't a Gentoo bug. The file permissions system is acting normally. Martin.vGagern@gmx.net 2007-08-20 20:02:27 0000 (In reply to comment #1) > Promote upstream. This isn't a Gentoo bug. The file permissions system is > acting normally. I've written a mail to bug-gnu-emacs@ and will set URL as soon as it appears on suitable archives. Just for the record: I've talked on the #emacs channel on freenode, and there someone was kind enough to try to reproduce this, without success. He reports his version like this: "ERC Version 5.2 with GNU Emacs 22.1.50.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-08-09, Ubuntu 6.06.1 LTS ("Dapper Drake")" I couldn't find out what exactly the relationship between that version and our 22.1 sources is, but maybe there already is a fix somewhere along the way. After running "M-x toggle-debug-on-quit" I could get a backtrace when pressing C-g. I've replaced all binary strings by "...". I guess the loop is in backup-buffer-copy. copy-file(".../foo.txt" ".../foo.txt~" nil t) byte-code("..." [from-name to-name nil (delete-file to-name) ((file-error)) copy-file t] 5) backup-buffer-copy(".../foo.txt" ".../foo.txt~" 420) byte-code("..." [file-precious-flag backup-by-copying modes real-file-name backup-by-copying-when-linked backup-by-copying-when-mismatch 0 logand 3072 file-writable-p file-name-directory file-nlinks 1 file-attributes 2 9 file-ownership-preserved-p backup-buffer-copy rename-file t backup-by-copying-when-privileged-mismatch attr backupname setmodes] 4) byte-code("..." [targets delete-old-versions real-file-name buffer-file-name modes buffer-backed-up t nil y-or-n-p format "Delete excess backup versions of %s? " file-modes (byte-code "..." [file-precious-flag backup-by-copying modes real-file-name backup-by-copying-when-linked backup-by-copying-when-mismatch 0 logand 3072 file-writable-p file-name-directory file-nlinks 1 file-attributes 2 9 file-ownership-preserved-p backup-buffer-copy rename-file t backup-by-copying-when-privileged-mismatch attr backupname setmodes] 4) ((file-error ...)) (byte-code "..." [targets delete-file] 2) ((file-error)) setmodes] 5) backup-buffer() basic-save-buffer-2() basic-save-buffer-1() basic-save-buffer() save-buffer(1) call-interactively(save-buffer) fauli@gentoo.org 2007-08-20 20:54:30 0000 On the other hand I cannot reproduce it. Neither with 22.1 nor CVS 22.1.50. Martin.vGagern@gmx.net 2007-08-20 21:22:19 0000 (In reply to comment #3) > On the other hand I cannot reproduce it. Neither with 22.1 nor CVS 22.1.50. OK, so let's try find differences. My USE flags for 22.1 are: X -Xaw3d alsa gif gtk -gzip-el -hesiod jpeg motif png -sound -source spell tiff -toolkit-scroll-bars xpm I could reproduce this with an environment only containing DISPLAY and XAUTHORITY, or nothing but TERM, so environment settings like locale don't seem to play a role, and neither does X vs. tty. Passing -Q makes no difference either, so it's not the init scripts. At least if under the same conditions you still can't reproduce the file. Martin.vGagern@gmx.net 2007-08-20 21:29:04 0000 Created an attachment (id=128715) strace fragment of 22.1 with bug happening This strace fragment shows what was going on when the bug happened. I used env -i TERM=$TERM strace -f -s 10240 -o ../strace /usr/bin/emacs-22 -Q foo.txt to strace emacs. I stripped the path before emacs-bug, to keep lines short. I have an ltrace as well, but that is less clean because of all those memory addresses. Also if I run ltrace with -f, at some point it tries to attach to PID 1, and is generally busy printing error messages. Somehow emacs doesn't play nice with ltrace. Martin.vGagern@gmx.net 2007-08-20 21:50:55 0000 I guess i puzzled out how the Lisp code in backup-buffer-copy actually works here (files.el, 3120 - 3130): (while (condition-case () (progn (condition-case nil (delete-file to-name) (file-error nil)) (copy-file from-name to-name nil t) nil) (file-already-exists t)) ;; The file was somehow created by someone else between ;; `delete-file' and `copy-file', so let's try again. nil)) condition-case is something like a try-catch, progn something like a block. So first it does delete the file, catching any file errors. Whatever the outcome of that inner condition-case, the progn simply discards it and goes on with the copy-file, which will throw a file-already-exists. This will cause the whole argument of while to become t instead of nil as it would if copy-file had succeeded. And as long as the argument of while is t, the loop continues. The code seems to make two wrong assumptions: 1. If I can't delete the file, it didn't exist in the first place 2. If the file exists after I tried delete it, someone else recreated it The solution should probably be a more elaborate handler for file-error. If the error is because the file doesn't exist, that's no problem at all, and the command may continue. If, however, the file does exist and cannot be deleted, this has to break the loop and probably be handled as an error or at leas a warning. An alternative would be to only try to delete the file if it does exist; in this case a file-error would always be a real error, not an expected situation. I still wonder how this same code could cause the bug /not/ to occur. Or maybe your code didn't run backup-buffer-copy at all, but for some reason chose a different one? Can you do "M-X debug-on-entry backup-buffer-copy"? If you save the file, you should get a debug frame if that function is used at all. ulm@gentoo.org 2007-08-21 06:02:20 0000 I can reproduce it with all versions 22.1 or newer, i.e. 22.1 as well as the currect CVS trunk (22.1.50), unicode-2 branch (23.0.0-r6), and multi-tty branch (23.0.51). Interestingly, the error does not occur for 21.4. For 21.4, Emacs displays the following message: Cannot write backup file; backing up in %backup%~ Comparing files.el, I noticed that function backup-buffer-copy is new in Emacs 22. And the corresponding condition-case for Emacs 21 (occurs twice, files.el lines 2199ff and 2219ff) contains an extra test for the case that the file exists but is not writable by us: (condition-case () (copy-file real-file-name backupname t t) (file-error ;; If copying fails because file BACKUPNAME ;; is not writable, delete that file and try again. (if (and (file-exists-p backupname) (not (file-writable-p backupname))) (delete-file backupname)) (copy-file real-file-name backupname t t))) ulm@gentoo.org 2007-08-21 06:29:28 0000 Created an attachment (id=128742) emacs-22.1-backup-buffer.patch Does the attached patch fix the problem for you? Martin.vGagern@gmx.net 2007-08-21 08:59:05 0000 (In reply to comment #8) > Created an attachment (id=128742) [edit] > emacs-22.1-backup-buffer.patch > > Does the attached patch fix the problem for you? Not yet. First I patched the files.el and ran byte-compile-file as root on it. Got one warning, and still the same error. Next I included the patch in the ebuild. Still the same issue. I noticed that files.elc hat a change date Jun 2, earlier than the patched files.el. Byte-compiling the file again gave me the same warning, corrected the date, but still the problem persists. Debugging the function shows me that the bytecode doesn't actually call file-exists-p at all. I guess the old version of the function got inlined into some other bytecode file. There seem to be quite a few of these in the source tarball. Is there some way to get the ebuild to rebuild all its .elc files? Martin.vGagern@gmx.net 2007-08-21 09:50:54 0000 (In reply to comment #9) Even after adding "emake -C lisp compile-always" to the src_compile, it still doesn't seem to call file-exists-p, and it still loops. ulm@gentoo.org 2007-08-21 10:55:15 0000 (In reply to comment #9) > Is there some way to get the ebuild to rebuild all its .elc files? Either you bootstrap: emake CC="$(tc-getCC)" bootstrap which is sort of overkill here, or use the method of emacs-21.4-r12.ebuild, i.e. add the following three lines at the end of src_compile(): einfo "Recompiling patched lisp files..." (cd lisp; emake recompile) || die emake CC="$(tc-getCC)" || die Martin.vGagern@gmx.net 2007-08-21 12:08:59 0000 Created an attachment (id=128764) Patch to ebuild to incorporate the fix (In reply to comment #11) > use the method of emacs-21.4-r12.ebuild, Works now. I'd never have thought of running make in the top level dir again. I've attached a patch to the ebuild. A bit different in formulation from what you originally suggested, but essentially the same. ulm@gentoo.org 2007-08-21 12:27:58 0000 (In reply to comment #12) > I've attached a patch to the ebuild. A bit different in formulation from > what you originally suggested, but essentially the same. The reason not to use option -C was that is a GNU make extension, and the ebuild should also run under FreeBSD (I don't know if -C exists there; it is a non-POSIX extension). Better play it safe, especially if there is a trivial equivalent like (cd; make). ulm@gentoo.org 2007-08-21 12:34:30 0000 Just wanted to post the patch to bug-gnu-emacs, but you were faster. ;) Lets wait for upstream's opinion about it. ulm@gentoo.org 2007-08-22 05:00:26 0000 Created an attachment (id=128827) emacs-22.1-backup-buffer.patch For whatever reason, upstream prefers a different approach. This is taken from the EMACS_22_BASE branch. (I've only included the first hunk since the rest are only comment changes.) Can you test if this works for you? Martin.vGagern@gmx.net 2007-08-22 19:03:45 0000 (In reply to comment #15) > Can you test if this works for you? Does work for my test case, yes. As you are aware, there is still some discussion on bug-gnu-emacs, where I posted a comment regarding that fix as well. Might perhaps be too filesystem-specific. ulm@gentoo.org 2007-08-24 07:35:02 0000 RMS locutus causa finita. ;-) Fixed in 22.1-r1, using my first patch from attachment #128742. Martin, thank you for reporting and for the good work. 128715 2007-08-20 21:29 0000 strace fragment of 22.1 with bug happening strace.txt text/plain c3RhdDY0KCIuLi4vZW1hY3MtYnVnL2Zvby50eHQiLCB7c3RfbW9kZT1TX0lGUkVHfDA2NDQsIHN0 X3NpemU9NCwgLi4ufSkgPSAwCmdldGV1aWQzMigpICAgICAgICAgICAgICAgICAgICAgICA9IDUw MApnZXRlZ2lkMzIoKSAgICAgICAgICAgICAgICAgICAgICAgPSAxMDAKZ2V0dWlkMzIoKSAgICAg ICAgICAgICAgICAgICAgICAgID0gNTAwCmdldGdpZDMyKCkgICAgICAgICAgICAgICAgICAgICAg ICA9IDEwMAphY2Nlc3MoIi4uLi9lbWFjcy1idWcvZm9vLnR4dCIsIFdfT0spID0gMApzdGF0NjQo Ii4uLi9lbWFjcy1idWcvZm9vLnR4dCIsIHtzdF9tb2RlPVNfSUZSRUd8MDY0NCwgc3Rfc2l6ZT00 LCAuLi59KSA9IDAKbHN0YXQ2NCgiLi4uL2VtYWNzLWJ1Zy9mb28udHh0Iiwge3N0X21vZGU9U19J RlJFR3wwNjQ0LCBzdF9zaXplPTQsIC4uLn0pID0gMApnZXRlZ2lkMzIoKSAgICAgICAgICAgICAg ICAgICAgICAgPSAxMDAKcmVhZGxpbmsoIi4uLi9lbWFjcy1idWcvZm9vLnR4dCIsIDB4ODViYTFm MCwgMTAwKSA9IC0xIEVJTlZBTCAoSW52YWxpZCBhcmd1bWVudCkKb3BlbigiLi4uL2VtYWNzLWJ1 ZyIsIE9fUkRPTkxZfE9fTk9OQkxPQ0t8T19MQVJHRUZJTEV8T19ESVJFQ1RPUlkpID0gMwpmc3Rh dDY0KDMsIHtzdF9tb2RlPVNfSUZESVJ8MDU1NSwgc3Rfc2l6ZT00MDk2LCAuLi59KSA9IDAKZmNu dGw2NCgzLCBGX1NFVEZELCBGRF9DTE9FWEVDKSAgID0gMApicmsoMHg4NWRkMDAwKSAgICAgICAg ICAgICAgICAgICAgPSAweDg1ZGQwMDAKZ2V0ZGVudHM2NCgzLCAvKiA0IGVudHJpZXMgKi8sIDQw OTYpID0gMTEyCmdldGRlbnRzNjQoMywgLyogMCBlbnRyaWVzICovLCA0MDk2KSA9IDAKY2xvc2Uo MykgICAgICAgICAgICAgICAgICAgICAgICAgID0gMApzdGF0NjQoIi4uLi9lbWFjcy1idWcvZm9v LnR4dCIsIHtzdF9tb2RlPVNfSUZSRUd8MDY0NCwgc3Rfc2l6ZT00LCAuLi59KSA9IDAKc3RhdDY0 KCIuLi4vZW1hY3MtYnVnLyIsIHtzdF9tb2RlPVNfSUZESVJ8MDU1NSwgc3Rfc2l6ZT00MDk2LCAu Li59KSA9IDAKc3RhdDY0KCIuLi4vZW1hY3MtYnVnLyIsIHtzdF9tb2RlPVNfSUZESVJ8MDU1NSwg c3Rfc2l6ZT00MDk2LCAuLi59KSA9IDAKZ2V0ZXVpZDMyKCkgICAgICAgICAgICAgICAgICAgICAg ID0gNTAwCmdldGVnaWQzMigpICAgICAgICAgICAgICAgICAgICAgICA9IDEwMApnZXR1aWQzMigp ICAgICAgICAgICAgICAgICAgICAgICAgPSA1MDAKZ2V0Z2lkMzIoKSAgICAgICAgICAgICAgICAg ICAgICAgID0gMTAwCmFjY2VzcygiLi4uL2VtYWNzLWJ1Zy8iLCBXX09LKSA9IC0xIEVBQ0NFUyAo UGVybWlzc2lvbiBkZW5pZWQpCnVtYXNrKDApICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAy Mgp1bWFzaygwMjIpICAgICAgICAgICAgICAgICAgICAgICAgPSAwCnVtYXNrKDA3NykgICAgICAg ICAgICAgICAgICAgICAgICA9IDAyMgpzdGF0NjQoIi4uLi9lbWFjcy1idWcvZm9vLnR4dH4iLCB7 c3RfbW9kZT1TX0lGUkVHfDA0NDQsIHN0X3NpemU9NCwgLi4ufSkgPSAwCnVubGluaygiLi4uL2Vt YWNzLWJ1Zy9mb28udHh0fiIpID0gLTEgRUFDQ0VTIChQZXJtaXNzaW9uIGRlbmllZCkKc3RhdDY0 KCIuLi4vZW1hY3MtYnVnL2Zvby50eHR+Iiwge3N0X21vZGU9U19JRlJFR3wwNDQ0LCBzdF9zaXpl PTQsIC4uLn0pID0gMApsc3RhdDY0KCIuLi4vZW1hY3MtYnVnL2Zvby50eHR+Iiwge3N0X21vZGU9 U19JRlJFR3wwNDQ0LCBzdF9zaXplPTQsIC4uLn0pID0gMApzdGF0NjQoIi4uLi9lbWFjcy1idWcv Zm9vLnR4dH4iLCB7c3RfbW9kZT1TX0lGUkVHfDA0NDQsIHN0X3NpemU9NCwgLi4ufSkgPSAwCnVu bGluaygiLi4uL2VtYWNzLWJ1Zy9mb28udHh0fiIpID0gLTEgRUFDQ0VTIChQZXJtaXNzaW9uIGRl bmllZCkKc3RhdDY0KCIuLi4vZW1hY3MtYnVnL2Zvby50eHR+Iiwge3N0X21vZGU9U19JRlJFR3ww NDQ0LCBzdF9zaXplPTQsIC4uLn0pID0gMApsc3RhdDY0KCIuLi4vZW1hY3MtYnVnL2Zvby50eHR+ Iiwge3N0X21vZGU9U19JRlJFR3wwNDQ0LCBzdF9zaXplPTQsIC4uLn0pID0gMAo= 128742 2007-08-21 06:29 0000 emacs-22.1-backup-buffer.patch emacs-22.1-backup-buffer.patch text/plain LS0tIGVtYWNzLTIyLjEub3JpZy9saXNwL2ZpbGVzLmVsCTIwMDctMDUtMjUgMTQ6NDM6MzEuMDAw MDAwMDAwICswMjAwCisrKyBlbWFjcy0yMi4xL2xpc3AvZmlsZXMuZWwJMjAwNy0wOC0yMSAwODoy NjozNi4wMDAwMDAwMDAgKzAyMDAKQEAgLTMxMTksOSArMzExOSw4IEBACiAJICAoc2V0LWRlZmF1 bHQtZmlsZS1tb2RlcyA/XDcwMCkKIAkgICh3aGlsZSAoY29uZGl0aW9uLWNhc2UgKCkKIAkJICAg ICAocHJvZ24KLQkJICAgICAgIChjb25kaXRpb24tY2FzZSBuaWwKLQkJCSAgIChkZWxldGUtZmls ZSB0by1uYW1lKQotCQkJIChmaWxlLWVycm9yIG5pbCkpCisJCSAgICAgICAoYW5kIChmaWxlLWV4 aXN0cy1wIHRvLW5hbWUpCisJCQkgICAgKGRlbGV0ZS1maWxlIHRvLW5hbWUpKQogCQkgICAgICAg KGNvcHktZmlsZSBmcm9tLW5hbWUgdG8tbmFtZSBuaWwgdCkKIAkJICAgICAgIG5pbCkKIAkJICAg KGZpbGUtYWxyZWFkeS1leGlzdHMgdCkpCg== 128764 2007-08-21 12:08 0000 Patch to ebuild to incorporate the fix emacs-22.1.ebuild.patch text/plain LS0tIC91c3IvLi9wb3J0YWdlL2FwcC1lZGl0b3JzL2VtYWNzL2VtYWNzLTIyLjEuZWJ1aWxkCTIw MDctMDYtMjUgMDg6MDc6NTkuMDAwMDAwMDAwICswMjAwCisrKyAvdXNyL2xvY2FsL3BvcnRhZ2Uv YXBwLWVkaXRvcnMvZW1hY3MvZW1hY3MtMjIuMS5lYnVpbGQJMjAwNy0wOC0yMSAxMzozMzowMC4w MDAwMDAwMDAgKzAyMDAKQEAgLTcwLDYgKzcwLDcgQEAgc3JjX3VucGFjaygpIHsKIAllcGF0Y2gg IiR7RklMRVNESVJ9LyR7UH0tWGF3M2QtaGVhZGVycy5wYXRjaCIKIAllcGF0Y2ggIiR7RklMRVNE SVJ9LyR7UH0tZnJlZWJzZC1zcGFyYy5wYXRjaCIKIAllcGF0Y2ggIiR7RklMRVNESVJ9LyR7UH0t b2xkeG1lbnUtcWEucGF0Y2giCisJZXBhdGNoICIke0ZJTEVTRElSfS8ke1B9LWJhY2t1cC1idWZm ZXIucGF0Y2giCiAJIyBBTFNBIGlzIGRldGVjdGVkIGFuZCB1c2VkIGV2ZW4gaWYgbm90IHJlcXVl c3RlZCBieSB0aGUgVVNFPWFsc2EgZmxhZy4KIAkjIFNvIHJlbW92ZSB0aGUgYXV0b21hZ2ljIGNo ZWNrCiAJdXNlIGFsc2EgfHwgZXBhdGNoICIke0ZJTEVTRElSfS8ke1B9LWRpc2FibGVfYWxzYV9k ZXRlY3Rpb24ucGF0Y2giCkBAIC0xMzcsNiArMTM4LDggQEAgc3JjX2NvbXBpbGUoKSB7CiAJCSR7 bXljb25mfSB8fCBkaWUgImVjb25mIGVtYWNzIGZhaWxlZCIKIAogCWVtYWtlIENDPSIkKHRjLWdl dENDKSIgfHwgZGllICJlbWFrZSBmYWlsZWQiCisJZW1ha2UgLUMgbGlzcCByZWNvbXBpbGUgfHwg ZGllICJlbWFrZSBsaXNwIGZhaWxlZCIKKwllbWFrZSBDQz0iJCh0Yy1nZXRDQykiIHx8IGRpZSAi ZW1ha2UgcnVuIDIgZmFpbGVkIgogfQogCiBzcmNfaW5zdGFsbCAoKSB7Cg== 128827 2007-08-22 05:00 0000 emacs-22.1-backup-buffer.patch emacs-22.1-backup-buffer.patch text/plain LS0tIGxpc3AvZmlsZXMuZWwJOCBBdWcgMjAwNyAxNDowNjowMSAtMDAwMAkxLjg5Ni4yLjE1Cisr KyBsaXNwL2ZpbGVzLmVsCTIyIEF1ZyAyMDA3IDAzOjQ3OjM1IC0wMDAwCTEuODk2LjIuMTYKQEAg LTMxMjAsNyArMzEyMCwxMiBAQAogCSAgICAoZmlsZS1lcnJvciBuaWwpKSkpKSkKIAogKGRlZnVu IGJhY2t1cC1idWZmZXItY29weSAoZnJvbS1uYW1lIHRvLW5hbWUgbW9kZXMpCi0gIChsZXQgKCh1 bWFzayAoZGVmYXVsdC1maWxlLW1vZGVzKSkpCisgIChsZXQgKCh1bWFzayAoZGVmYXVsdC1maWxl LW1vZGVzKSkKKwkoZGlyIChvciAoZmlsZS1uYW1lLWRpcmVjdG9yeSB0by1uYW1lKQorCQkgZGVm YXVsdC1kaXJlY3RvcnkpKSkKKyAgICA7OyBDYW4ndCBkZWxldGUgb3IgY3JlYXRlIGZpbGVzIGlu IGEgcmVhZC1vbmx5IGRpcmVjdG9yeS4KKyAgICAodW5sZXNzIChmaWxlLXdyaXRhYmxlLXAgZGly KQorICAgICAgKHNpZ25hbCAnZmlsZS1lcnJvciAobGlzdCAiRGlyZWN0b3J5IGlzIG5vdCB3cml0 YWJsZSIgZGlyKSkpCiAgICAgKHVud2luZC1wcm90ZWN0CiAJKHByb2duCiAJICA7OyBDcmVhdGUg dGVtcCBmaWxlcyB3aXRoIHN0cmljdCBhY2Nlc3MgcmlnaHRzLiAgSXQncyBlYXN5IHRvCg==