GNU bug report logs - #28792
26.0.60; Deleting to a custom trash directory in Dired gives error

Previous Next

Full log

View this message in rfc822 format

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Göktuğ Kayaalp <self <at> gkayaalp.com>
Cc: eggert <at> cs.ucla.edu, 28792 <at> debbugs.gnu.org
Subject: bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error
Date: Thu, 12 Oct 2017 13:02:31 +0000

[Message part 1 (text/plain, inline)]

On Thu, Oct 12, 2017 at 8:58 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> This use case raises an interesting question: what should be the
> behavior of delete-by-moving-to-trash when the Trash directory already
> includes a directory by the same name as the non-directory file being
> deleted?  Are files in the Trash directory generally unimportant
> enough to disregard these situations, or does this use case run afoul
> of the ability to restore the trashed files later?
>

The fact that the user deleted the files means that the files were not
important. If the user deleted them by mistake, then the trash serves as a
last-resort to restore the files from. Trash is not a "backup".. so unlike
the Emacs backup, there shouldn't be a need to store multiple revisions of
trash.

IMO, if a file or a directory exists by the same name in trash, the
move-file-to-trash should just overwrite that.. if a foo file already
exists and a foo/ dir is being trashed, then just delete the old trashed
foo file and replace with the newly trashed foo/ dir.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Previous Next

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