GNU bug report logs - #1440
23.0.60; delete-by-moving-to-trash loses data

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1440 in the body.
You can then email your comments to 1440 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; delete-by-moving-to-trash loses data
Date: Thu, 27 Nov 2008 16:44:09 +0100

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 <at> gnu.org mailing list.

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=/usr' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-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=gtk' '--without-hesiod' '--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus' '--build=x86_64-pc-linux-gnu' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-g -ggdb -O1 -pipe' 'LDFLAGS=''

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:
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <backspace> SPC 
c a l l s M-q <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> s M-q <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <down> <down> <return> <return> b <tab> C-c 
C-c c <return> SPC SPC SPC S W C-k C-k C-k C-k C-k 
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 
SPC W o l f g a n g , <return> <down> <down> <return> 
<up> <return> P r i m a ! SPC ; - ) <return> <down> 
M-q <down> <down> C-k C-k C-k C-k C-k C-k <return> 
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 
g e n a u s e <backspace> o SPC w i e SPC f ü r SPC 
G N H <backspace> U . SPC SPC F r i s c h SPC a u s 
SPC d e m SPC C V S S-SPC u n d SPC z u m SPC s e l 
b e r k o m p i l i e r e n . M-q <M-left> <M-left> 
<M-right> <M-backspace> <backspace> M-q <end> <down> 
<down> <down> <down> SPC SPC <backspace> <backspace> 
<return> <return> g <tab> C-c C-c c <return> SPC c 
l s 1 g <down> <down> <down> <return> <return> M-2 
<tab> <tab> <return> <help-echo> <down-mouse-1> <mouse-1> 
q <return> SPC ^ ^ ^ ^ ^ M-1 M-2 <down> <down> <down> 
C-SPC <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <up> M-w M-x r e b <return> <return>

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

-- 
      "OS's and GUI's come and go, only Emacs has lasting power."
          Per Abrahamsen in <rjbsysc7n1.fsf <at> zuse.dina.kvl.dk>

Message #10 received at 1440 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: 1440 <at> debbugs.gnu.org
Subject: Re: Concerning delete-by-moving-to-trash on free systems
Date: Fri, 28 Nov 2008 18:53:34 +0000

> 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.)

Message #15 received at 1440 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Tassilo Horn <tassilo <at> member.fsf.org>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 1440 <at> debbugs.gnu.org
Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems
Date: Fri, 28 Nov 2008 22:58:44 +0100

David De La Harpe Golden <david <at> harpegolden.net> 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

Message #20 received at 1440 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: 1440 <at> debbugs.gnu.org, Tassilo Horn <tassilo <at> member.fsf.org>
Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems
Date: Mon, 01 Dec 2008 20:00:21 +0000

> 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)

Message #25 received at 1440-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Tassilo Horn <tassilo <at> member.fsf.org>
Cc: David De La Harpe Golden <david <at> harpegolden.net>,
        1440-done <at> 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

> > 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.

Message #26 received at 1440-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Tassilo Horn <tassilo <at> member.fsf.org>,
        1440-done <at> debbugs.gnu.org
Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems
Date: Sun, 28 Dec 2008 20:34:37 +0000

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...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.