From tassilo@member.fsf.org Thu Nov 27 07:44:20 2008 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=-8.4 required=4.0 tests=AWL,BAYES_00,FOURLA, IMPRONONCABLE_2,MURPHY_DRUGS_REL8,RCVD_IN_DNSWL_MED autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at submit) by emacsbugs.donarmstrong.com; 27 Nov 2008 15:44:20 +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 mARFiGe1016357 for ; Thu, 27 Nov 2008 07:44:17 -0800 Received: from mx10.gnu.org ([199.232.76.166]:33760) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1L5j24-0000J3-C8 for emacs-pretest-bug@gnu.org; Thu, 27 Nov 2008 10:43:56 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1L5j2M-0001b2-EI for emacs-pretest-bug@gnu.org; Thu, 27 Nov 2008 10:44:15 -0500 Received: from deliver.uni-koblenz.de ([141.26.64.15]:27472) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5j2L-0001aq-To for emacs-pretest-bug@gnu.org; Thu, 27 Nov 2008 10:44:14 -0500 Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 3A9F3789AB5C for ; Thu, 27 Nov 2008 16:44:13 +0100 (CET) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27778-02-2 for ; Thu, 27 Nov 2008 16:44:10 +0100 (CET) X-CHKRCPT: Envelopesender vrfy tassilo@member.fsf.org Received: from thinkpad.tsdh.de (dhcp83.uni-koblenz.de [141.26.71.83]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 2FB20789AB56 for ; Thu, 27 Nov 2008 16:44:09 +0100 (CET) From: Tassilo Horn To: emacs-pretest-bug@gnu.org Subject: 23.0.60; delete-by-moving-to-trash loses data Mail-Copies-To: never Severity: grave Date: Thu, 27 Nov 2008 16:44:09 +0100 Message-ID: <87hc5trx6e.fsf@thinkpad.tsdh.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: amavisd-new at uni-koblenz.de X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Severity: grave Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing lis= t. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I've just found out about delete-by-moving-to-trash, and basically it sounds nice, but it's dangerous. The current implementation has one minor and one HUGE drawback. - Delete a directory foo which contains the files a and b recursively (from within dired). Then goto the trash-directory. Now foo, a and b are side by side. - Now delete another file named a. This file is really deleted, because a already exists in trash. (Overwriting would be as bad as the current decision.) In Bug #973 David De La Harpe Golden added a patch to implement the freedesktop.org trashcan spec, which solves both problems and integrates emacs much better into the modern GNU desktop. He implemented only the writing part, so currently one has to use some desktop file manager to restore files properly, but as long as no data is lost, I wouldn't consiter that a problem. If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /usr/share/emacs/23.0.60/etc/DEBUG for instructions. In GNU Emacs 23.0.60.1 (x86_64-pc-linux-gnu, GTK+ Version 2.14.4) of 2008-11-25 on thinkpad Windowing system distributor `The X.Org Foundation', version 11.0.10502000 configured using `configure '--prefix=3D/usr' '--host=3Dx86_64-pc-linux-gn= u' '--mandir=3D/usr/share/man' '--infodir=3D/usr/share/info' '--datadir=3D/= usr/share' '--sysconfdir=3D/etc' '--localstatedir=3D/var/lib' '--libdir=3D/= usr/lib64' '--program-suffix=3D-emacs-23' '--infodir=3D/usr/share/info/emac= s-23' '--with-sound' '--with-x' '--with-toolkit-scroll-bars' '--with-gif' '= --with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-= freetype' '--with-xft' '--with-libotf' '--with-m17n-flt' '--with-x-toolkit= =3Dgtk' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--wi= th-gpm' '--with-dbus' '--build=3Dx86_64-pc-linux-gnu' 'build_alias=3Dx86_64= -pc-linux-gnu' 'host_alias=3Dx86_64-pc-linux-gnu' 'CFLAGS=3D-g -ggdb -O1 -p= ipe' 'LDFLAGS=3D'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Article Minor modes in effect: rcirc-track-minor-mode: t yas/minor-mode: t shell-dirtrack-mode: t recentf-mode: t iswitchb-mode: t window-number-meta-mode: t window-number-mode: t savehist-mode: t exec-abbrev-cmd-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: (only . t) Recent input: =20 SPC=20 c a l l s M-q =20 s M-q =20 =20 =20 =20 =20 b C-c=20 C-c c SPC SPC SPC S W C-k C-k C-k C-k C-k=20 C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k H i=20 SPC W o l f g a n g , =20 P r i m a ! SPC ; - ) =20 M-q C-k C-k C-k C-k C-k C-k =20 C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k J a , SPC=20 g e n a u s e o SPC w i e SPC f =FC r SPC=20 G N H U . SPC SPC F r i s c h SPC a u s=20 SPC d e m SPC C V S S-SPC u n d SPC z u m SPC s e l=20 b e r k o m p i l i e r e n . M-q =20 M-q =20 SPC SPC =20 g C-c C-c c SPC c=20 l s 1 g M-2=20 =20 q SPC ^ ^ ^ ^ ^ M-1 M-2 =20 C-SPC =20 =20 M-w M-x r e b Recent messages: 20081127T163816.052> Generating summary...done 20081127T163817.169> Generating summary... 20081127T163817.172> Generating summary...done 20081127T163818.539> Generating summary... 20081127T163818.542> Generating summary...done 20081127T163819.674> Generating summary... 20081127T163819.677> Generating summary...done 20081127T163820.704> Generating summary... 20081127T163820.708> Generating summary...done Mark set --=20 "OS's and GUI's come and go, only Emacs has lasting power." Per Abrahamsen in From david@harpegolden.net Fri Nov 28 10:53:43 2008 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=-4.0 required=4.0 tests=BAYES_00,MURPHY_DRUGS_REL8, SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1440) by emacsbugs.donarmstrong.com; 28 Nov 2008 18:53:44 +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 mASIrfjI014829 for <1440@emacsbugs.donarmstrong.com>; Fri, 28 Nov 2008 10:53:42 -0800 Received: from [87.198.54.44] (87-198-54-44.ptr.magnet.ie [87.198.54.44]) (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 841BB8322 for <1440@emacsbugs.donarmstrong.com>; Fri, 28 Nov 2008 18:53:40 +0000 (GMT) Message-ID: <49303E2E.6080706@harpegolden.net> Date: Fri, 28 Nov 2008 18:53:34 +0000 From: David De La Harpe Golden User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: 1440@debbugs.gnu.org Subject: Re: Concerning delete-by-moving-to-trash on free systems References: <87od01tr8o.fsf@thinkpad.tsdh.de> <492E9E4D.7040108@harpegolden.net> <87d4ghtgkf.fsf@thinkpad.tsdh.de> <492EB022.8080905@harpegolden.net> <87tz9trzb8.fsf@thinkpad.tsdh.de> <878wr5rvik.fsf@thinkpad.tsdh.de> In-Reply-To: <878wr5rvik.fsf@thinkpad.tsdh.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Delete a directory foo which contains the files a and b recursively > (from within dired). Then goto the trash-directory. Now foo, a and > b are side by side. Not 100% sure, but one guess: maybe dired is itself recursing into the directory and deleting each file and then deleting the directory rather than deleting the directory as one operation, thus causing the flattening. > Now delete another file named a. This file is really deleted, > because a already exists in trash. (Overwriting would be as bad as > the current decision.) Uh. Not that I'm a fan of the current builtin trashcan routine, but are you sure that it is actually losing data? The current emacs move-file-to-trash _should_ be generating alternative in-trash names for files with clashing filenames with find-backup-file-name , see function body. Some GUI file managers may be treating the generated names as "hidden" backup files due to the naming scheme - can you verify you don't have "a.~1~" files in your ~/.Trash/ directory from the command line? (My fd.o trashcan patch avoids using such filenames because turns out several GUI file managers actually choke on them (see patch commentary), btw, so if you've also adjusted your unpatched-with-my-patch-emacs trash-directory to point to the sepcial fd.o trashcan directory, then things will go, um, wronger.) From tassilo@member.fsf.org Fri Nov 28 13:58:54 2008 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=-6.7 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1440) by emacsbugs.donarmstrong.com; 28 Nov 2008 21:58:54 +0000 Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mASLwova029936 for <1440@emacsbugs.donarmstrong.com>; Fri, 28 Nov 2008 13:58:52 -0800 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3CF1B1C8F8A; Fri, 28 Nov 2008 16:58:50 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 28 Nov 2008 16:58:50 -0500 X-Sasl-enc: f4VmxbFRwsEaT6GAKNJMjbPlnsPasLFEj7j/1tVQ5XeQ 1227909529 Received: from thinkpad.tsdh.de (p54AF254C.dip0.t-ipconnect.de [84.175.37.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 18CD02BC8D; Fri, 28 Nov 2008 16:58:48 -0500 (EST) From: Tassilo Horn To: David De La Harpe Golden Cc: 1440@debbugs.gnu.org Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems References: <87od01tr8o.fsf@thinkpad.tsdh.de> <492E9E4D.7040108@harpegolden.net> <87d4ghtgkf.fsf@thinkpad.tsdh.de> <492EB022.8080905@harpegolden.net> <87tz9trzb8.fsf@thinkpad.tsdh.de> <878wr5rvik.fsf@thinkpad.tsdh.de> Date: Fri, 28 Nov 2008 22:58:44 +0100 In-Reply-To: (David De La Harpe Golden's message of "Fri, 28 Nov 2008 18:53:34 +0000") Message-ID: <877i6ncy23.fsf@thinkpad.tsdh.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii David De La Harpe Golden writes: >> Delete a directory foo which contains the files a and b recursively >> (from within dired). Then goto the trash-directory. Now foo, a and >> b are side by side. > > Not 100% sure, but one guess: maybe dired is itself recursing into the > directory and deleting each file and then deleting the directory > rather than deleting the directory as one operation, thus causing the > flattening. Yes, that's likely. Anyway, I don't think that is what users would expect and it makes recovery of deleted directories difficult. >> Now delete another file named a. This file is really deleted, >> because a already exists in trash. (Overwriting would be as bad as >> the current decision.) > > Uh. Not that I'm a fan of the current builtin trashcan routine, but > are you sure that it is actually losing data? > > The current emacs move-file-to-trash _should_ be generating > alternative in-trash names for files with clashing filenames with > find-backup-file-name, see function body. > > Some GUI file managers may be treating the generated names as "hidden" > backup files due to the naming scheme I use dired. > - can you verify you don't have "a.~1~" files in your ~/.Trash/ > directory from the command line? Yes. But I have ,----[ C-h v backup-directory-alist RET ] | backup-directory-alist is a variable defined in `files.el'. | Its value is | ((".*" . "~/.backupFiles/")) `---- and indeed, there are the backup files. I'd propose to let-unbind backup-directory-alist when making backups for deleted files. They always should be in .Trash. Bye, Tassilo From david@harpegolden.net Mon Dec 1 12:00:32 2008 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=-4.2 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER, MURPHY_DRUGS_REL8,SPF_HELO_PASS autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02 Received: (at 1440) by emacsbugs.donarmstrong.com; 1 Dec 2008 20:00:32 +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 mB1K0TG6006081 for <1440@emacsbugs.donarmstrong.com>; Mon, 1 Dec 2008 12:00:30 -0800 Received: from [87.198.54.45] (87-198-54-45.ptr.magnet.ie [87.198.54.45]) (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 AD9F08313; Mon, 1 Dec 2008 20:00:28 +0000 (GMT) Message-ID: <49344255.5010401@harpegolden.net> Date: Mon, 01 Dec 2008 20:00:21 +0000 From: David De La Harpe Golden User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: 1440@debbugs.gnu.org, Tassilo Horn Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > I'd propose to let-unbind backup-directory-alist when making backups > for deleted files. That seems sensible/necessary. Though I think that maybe backup and trashing code paths should just be decoupled to avoid ongoing problems - i.e. have move-file-to-trash just not use find-backup-file-name. What happens when someone next changes the backup-file subsystem, or a user locally patches it? fallback trashing silently breaks, of course, surprise! There's also the minor point that find-file-name handlers can't distinguish a fallback trash operation from a backup operation at present and might conceivably do the wrong thing. And of course, all this is about fixing the fallback trashcan, which as already noted doesn't correspond to the free desktop trashcan. It probably isn't a proper implementation of the macosx trashcan really either (should probably really be using the relevant system trash api on that platform , which appears to be (though I'm not a macosx programmer, just cursory google search) NSWorkspaceRecycleOperation or maybe FSMoveObjectToTrashSync) From cyd@stupidchicken.com Sat Dec 27 19:19:45 2008 Received: (at 1440-done) by emacsbugs.donarmstrong.com; 28 Dec 2008 03:19:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from cyd.mit.edu (CYD.MIT.EDU [18.115.2.24]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id mBS3Jgjl029477 for <1440-done@emacsbugs.donarmstrong.com>; Sat, 27 Dec 2008 19:19:43 -0800 Received: by cyd.mit.edu (Postfix, from userid 1000) id 193A257E217; Sat, 27 Dec 2008 22:19:52 -0500 (EST) From: Chong Yidong To: Tassilo Horn Cc: David De La Harpe Golden , 1440-done@debbugs.gnu.org Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems Date: Sat, 27 Dec 2008 22:19:52 -0500 Message-ID: <87fxk9htpj.fsf@cyd.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > > I'd propose to let-unbind backup-directory-alist when making backups > > for deleted files. > > That seems sensible/necessary. Done. David's patch in bug#973, which implements the Freedesktop trash can, looks good... but I think we should wait till after the release to include it. From david@harpegolden.net Sun Dec 28 12:34:55 2008 Received: (at 1440-done) by emacsbugs.donarmstrong.com; 28 Dec 2008 20:34:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 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 mBSKYm0W003562 for <1440-done@emacsbugs.donarmstrong.com>; Sun, 28 Dec 2008 12:34:49 -0800 Received: from [87.198.47.26] (87-198-47-26.ptr.magnet.ie [87.198.47.26]) (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 1373D8159; Sun, 28 Dec 2008 20:34:46 +0000 (GMT) Message-ID: <4957E2DD.7080408@harpegolden.net> Date: Sun, 28 Dec 2008 20:34:37 +0000 From: David De La Harpe Golden User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: Chong Yidong CC: Tassilo Horn , 1440-done@debbugs.gnu.org Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems References: <87fxk9htpj.fsf@cyd.mit.edu> In-Reply-To: <87fxk9htpj.fsf@cyd.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Chong Yidong wrote: >>> I'd propose to let-unbind backup-directory-alist when making backups >>> for deleted files. >> That seems sensible/necessary. > > Done. > [Note that the "hierarchy flattening" issue in 1440 isn't addressed by that, though maybe should not be considered grave/release-blocking] BTW, I now think there are further trash (or underlying file/directory operations) problems in some cross-device dir-tree trashing contexts (possibly for both the fallback trash and fd.o patch), will try and make a reproducible case and file a new bug I guess, holiday season commitments slowing me a bit, sorry. > David's patch in bug#973, which implements the Freedesktop trash can, > looks good... but I think we should wait till after the release to > include it. Wouldn't really want to cause release delay because of it (and it would need testing, and might have knock-on effects e.g. needing to (re)write macosx trashcan support - I don't even have a macosx box at present, I for one can't do that very easily). Obvious concern would be if trashcan support is being newly introduced, doing fd.o trashing from the start on platforms that use fd.o trash would avoid confusion* and bug reports. * Particularly inventive end-users redirecting the fallback trash at the fd.o trash path rather than at the fallback trash's default path will make a bit of a mess in their fd.o trash (fd.o apps will wonder where the undelete metadata is), might want to keep an eye out for that - not really a bug in the emacs fallback trash if such metadata isn't recorded by it if it's not an implementation of fd.o trashing in the first place... From unknown Sat Jun 21 10:39:25 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: $requester Subject: Internal Control Message-Id: bug archived. Date: Mon, 26 Jan 2009 15:24:06 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A log time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator