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

Previous Next

Full log

Message #17 received at 28792 <at> debbugs.gnu.org (full text, mbox):

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

> From: Göktuğ Kayaalp <self <at> gkayaalp.com>
> Date: Thu, 12 Oct 2017 15:50:26 +0300
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 28792 <at> debbugs.gnu.org
> 
> Quite recently I've opened and retreated the similar bug#28791, trying
> to trash directories recursively.  I did not use a custom
> trash-directory, but I got the same error.  Turns out that it was
> delete-by-moving-to-trash that provoked the error (with an indentical
> message to yours).  Emptying the ~/.local/share/Trash/ folder solved the
> issue for me.  I observed that in ~/.local/share/Trash/info/ some
> .trashinfo files were created with the name of the directory (say
> <dirname>) I was trying to delete, one <dirname>.trashinfo and many
> <dirname><random bits>.trashinfo.

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?

I don't know the answers, as I intentionally avoid using the system
trash.

Previous Next

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