From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.bugs Subject: bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan Date: Wed, 27 Jan 2010 00:06:11 +0000 Message-ID: <4B5F8373.7080004@harpegolden.net> References: <87ljfqkt6e.fsf@stupidchicken.com> <4B5BC912.3050409@harpegolden.net> <87my02au2h.fsf@stupidchicken.com> <4B5E2A32.6010306@harpegolden.net> <87ockghmy6.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1264551813 20111 80.91.229.12 (27 Jan 2010 00:23:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2010 00:23:33 +0000 (UTC) Cc: Tassilo Horn , 5436@debbugs.gnu.org To: Chong Yidong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 27 01:23:24 2010 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 1NZvgo-0000In-IT for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jan 2010 01:23:22 +0100 Original-Received: from localhost ([127.0.0.1]:60499 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZvgp-0005dv-Og for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jan 2010 19:23:23 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZvTo-00019p-GK for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2010 19:09:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZvTl-000189-0W for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2010 19:09:56 -0500 Original-Received: from [199.232.76.173] (port=33967 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZvTk-000182-KG for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2010 19:09:52 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35628) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NZvTk-0006V0-7G for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2010 19:09:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NZvQz-0008Ix-TR; Tue, 26 Jan 2010 19:07:01 -0500 X-Loop: bug-gnu-emacs@gnu.org Resent-From: David De La Harpe Golden Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jan 2010 00:07:01 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5436 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 5436-submit@debbugs.gnu.org id=B5436.126455078031910 (code B ref 5436); Wed, 27 Jan 2010 00:07:01 +0000 Original-Received: (at 5436) by debbugs.gnu.org; 27 Jan 2010 00:06:20 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NZvQK-0008Id-37 for submit@debbugs.gnu.org; Tue, 26 Jan 2010 19:06:20 -0500 Original-Received: from harpegolden.net ([65.99.215.13]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NZvQH-0008IX-P3 for 5436@debbugs.gnu.org; Tue, 26 Jan 2010 19:06:18 -0500 Original-Received: from [87.198.54.168] (87-198-54-168.ptr.magnet.ie [87.198.54.168]) (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 3E0308ABB; Wed, 27 Jan 2010 00:06:13 +0000 (GMT) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) In-Reply-To: <87ockghmy6.fsf@stupidchicken.com> X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list X-Spam-Score: -2.6 (--) Resent-Date: Tue, 26 Jan 2010 19:07:01 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , 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:34739 Archived-At: Chong Yidong wrote: > I understand what you are saying. How about conditioning the > delete-directory change on delete-by-moving-to-trash? Unless I'm misunderstanding you (or did you mean the rename-file change?*): delete-directory with the delete-directory part of the patch already becomes conditionalised on delete-by-moving-to-trash. See the patch introducing "(if delete-by-moving-to-trash ...[a]... ...[b]...)" [a] delete-by-moving-to-trash non-nil, delete-directory called with a directory arg and arg recursive non-nil: a single call to move-file-to-trash is made in delete-directory, so that move-file-to-trash can handle the directory tree as a unit**. [b] delete-by-moving-to-trash nil, delete-directory called with a directory arg and arg recursive non-nil: the original self-recursive code path in delete-directory is used - it's really deleting, so delete-directory just walks the tree and deletes everything, calling itself recursively - there's no need for renames and copies in this case, so what happens cross-device doesn't matter*** * If so, I think that would be a tad confusing, anyway. Probably possible, but would be getting a bit difficult to follow IMO (remember even an unpatched rename-file already wraps delete-by-moving-to-trash to nil around a call to delete-file.) ** With the other part of the patch (the more controversial change to rename-file), when move-file-to-trash then calls the extended rename-file to actually do the move, the extended rename-file may call delete-directory again, but with with delete-by-moving-to-trash dynamically bound to nil around it to really delete after copy-directory, meaning path [a] does ultimately internally sometimes use path [b]. That is highly similar to the way the unpatched rename-file calls delete-file in the xdev with delete-by-moving-to-trash bound to nil around it to really delete files after copy-file, emulating a rename cross-device. *** come to think of it, except for mountpoints that exist below the directory being deleted ...wonder what happens then...