From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: don@donarmstrong.com (Emacs bug Tracking System) Newsgroups: gmane.emacs.bugs Subject: bug#964: marked as done (trash - runaway recursion for cross-device delete-file ops) Date: Sat, 20 Sep 2008 14:50:03 -0700 Message-ID: References: <48C9CEE3.90006@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1221947403-14010-0" X-Trace: ger.gmane.org 1221948480 8780 80.91.229.12 (20 Sep 2008 22:08:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Sep 2008 22:08:00 +0000 (UTC) To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 21 00:08:57 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KhAdL-0000SU-K1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Sep 2008 00:08:56 +0200 Original-Received: from localhost ([127.0.0.1]:44295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhAcJ-0004lW-Vs for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Sep 2008 18:07:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KhAcC-0004i1-Md for bug-gnu-emacs@gnu.org; Sat, 20 Sep 2008 18:07:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KhAcB-0004hX-Td for bug-gnu-emacs@gnu.org; Sat, 20 Sep 2008 18:07:44 -0400 Original-Received: from [199.232.76.173] (port=58785 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KhAcB-0004hS-OT for bug-gnu-emacs@gnu.org; Sat, 20 Sep 2008 18:07:43 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:57106) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KhAc5-0005Z1-Oz; Sat, 20 Sep 2008 18:07:38 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m8KM7ZM2021267; Sat, 20 Sep 2008 15:07:36 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m8KLo32P014105; Sat, 20 Sep 2008 14:50:03 -0700 X-Mailer: MIME-tools 5.420 (Entity 5.420) X-Loop: don@donarmstrong.com X-Emacs-PR-Message: closed 964 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: patch X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:20679 Archived-At: This is a multi-part message in MIME format... ------------=_1221947403-14010-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your message dated Sat, 20 Sep 2008 17:40:39 -0400 with message-id and subject line Re: bug#964: trash - runaway recursion for cross-device de= lete-file ops has caused the Emacs bug report #964, regarding trash - runaway recursion for cross-device delete-file ops to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact don@donarmstrong.com immediately.) --=20 964: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3D964 Emacs Bug Tracking System Contact don@donarmstrong.com with problems ------------=_1221947403-14010-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-7.1 required=4.0 tests=AWL,BAYES_00,FVGT_m_MULTI_ODD, HAS_PACKAGE,MIXEDBDN,MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 12 Sep 2008 02:07:49 +0000 Received: from harpegolden.net (harpegolden.net [65.99.215.13]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m8C27j7Z026243 for ; Thu, 11 Sep 2008 19:07:46 -0700 Received: from golden1.harpegolden.net (unknown [86.45.15.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 310CF81AD for ; Fri, 12 Sep 2008 03:07:44 +0100 (IST) Message-ID: <48C9CEE3.90006@harpegolden.net> Date: Fri, 12 Sep 2008 03:07:31 +0100 From: David De La Harpe Golden User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: submit@emacsbugs.donarmstrong.com Subject: trash - runaway recursion for cross-device delete-file ops X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------040105050802060801010406" This is a multi-part message in MIME format. --------------040105050802060801010406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Package: emacs Version: 23.0.60 Severity: normal Tags: patch Steps to reproduce: Turn on delete-by-moving-to-trash on gnu+linux. Make a file on a different filesystem to your home dir. Try to delete-file the file in emacs once. Look inside ~/.Trash, full of hundreds of redundant copies of the file. Reason: When delete-by-moving-to-trash is on, delete-file calls move-file-to-trash. move-file-to-trash, when using its fallback emacs trashcan implementation* (i.e. when there's no system-move-file-to-trash) picks a name for the trashed file, and calls rename-file. rename-file tries a C rename(), but that doesn't work cross-device on gnu+linux (and several other OSes), so rename-file falls back to copying the file to the new name, and then calls delete-file to get rid of the old one (~line 2247 of fileio.c) move-file-to-trash decides the existing filename under .Trash is taken, seeing as a file exists with that name, picks a new name, and calls rename-file again... ... Lather, rinse, repeat, until emacs gets bored with a "Variable binding depth exceeds max-specpdl-size" Fix?: (i) Well, binding delete-by-moving-to-trash to nil around the rename-file in move-file-to-trash might be adequate, fixes immediate issue? trivial patch attached. Though another strikes me: (ii) As it stands, won't an actual rename-file will sometimes move a copy of "renamed" files to trash (i.e. when they're on a different device) if delete-by-moving-to-trash is on? Not sure that's very nice - maybe should bind delete-by-moving-to-trash to nil around its call to delete-file, or maybe just use C unlink()? * which really isn't suitable for gnu+linux/freedesktop.org desktops, it seems to be something very like (if not identical to) the macosx convention, but that's a matter for a different bug. --------------040105050802060801010406 Content-Type: text/x-patch; name="trash_xdevice_fix_r1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="trash_xdevice_fix_r1.diff" Index: lisp/files.el =================================================================== RCS file: /sources/emacs/emacs/lisp/files.el,v retrieving revision 1.995 diff -U 8 -r1.995 files.el --- lisp/files.el 2 Sep 2008 16:10:44 -0000 1.995 +++ lisp/files.el 12 Sep 2008 01:43:51 -0000 @@ -5820,17 +5820,18 @@ ;; make new-fn unique. ;; example: "~/.Trash/abc.txt" -> "~/.Trash/abc.txt.~1~" (let ((version-control t)) (setq new-fn (car (find-backup-file-name new-fn))))) ;; stop processing if fn is same or parent directory of trash-dir. (and (string-match fn trash-dir) (error "Filename `%s' is same or parent directory of trash-directory" filename)) - (rename-file fn new-fn))))) + (let ((delete-by-moving-to-trash nil)) + (rename-file fn new-fn)))))) (define-key ctl-x-map "\C-f" 'find-file) (define-key ctl-x-map "\C-r" 'find-file-read-only) (define-key ctl-x-map "\C-v" 'find-alternate-file) (define-key ctl-x-map "\C-s" 'save-buffer) (define-key ctl-x-map "s" 'save-some-buffers) (define-key ctl-x-map "\C-w" 'write-file) --------------040105050802060801010406 Content-Type: text/plain; name="ChangeLog.trash_xdevice_fix_r1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ChangeLog.trash_xdevice_fix_r1" 2008-09-11 David De La Harpe Golden files.el: in move-file-to-trash, bind delete-by-moving-to-trash to nil around rename-file to avoid recursive trashing if rename-file calls delete-file. --------------040105050802060801010406-- ------------=_1221947403-14010-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02 (2007-08-08) on rzlab.ucr.edu X-Spam-Level: X-Spam-Status: No, score=-12.1 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED,X_DEBBUGS_NO_ACK autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 964-done) by emacsbugs.donarmstrong.com; 20 Sep 2008 21:42:44 +0000 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m8KLgfFs011993 for <964-done@emacsbugs.donarmstrong.com>; Sat, 20 Sep 2008 14:42:42 -0700 Received: from rgm by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KhABz-0004lA-Qm; Sat, 20 Sep 2008 17:40:39 -0400 From: Glenn Morris To: David De La Harpe Golden Cc: 964-done@emacsbugs.donarmstrong.com Subject: Re: bug#964: trash - runaway recursion for cross-device delete-file ops References: <48C9CEE3.90006@harpegolden.net> X-Spook: Centro Adriatic Leitrim lock picking explosion TWA Steve X-Ran: dIrGC*z}/f4qND=KT%M+Hd#M~D!+`u/!7,QSJ<{^}09Miwd[|_}HLtOEVLnh>QY~t'q<3h X-Hue: green X-Debbugs-No-Ack: yes X-Attribution: GM Date: Sat, 20 Sep 2008 17:40:39 -0400 In-Reply-To: <48C9CEE3.90006@harpegolden.net> (David De La Harpe Golden's message of "Fri, 12 Sep 2008 03:07:31 +0100") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii David De La Harpe Golden wrote: > (i) Well, binding delete-by-moving-to-trash to nil around the > rename-file in move-file-to-trash might be adequate, fixes immediate > issue? trivial patch attached. Thanks; applied. > (ii) As it stands, won't an actual rename-file will sometimes move a > copy of "renamed" files to trash (i.e. when they're on a different > device) if delete-by-moving-to-trash is on? Not sure that's very nice - > maybe should bind delete-by-moving-to-trash to nil around its call to > delete-file, or maybe just use C unlink()? I installed a fix using the former approach. This feature doesn't seem very well thought-out on non-Windows platforms. ------------=_1221947403-14010-0--