bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error

["Göktuğ Kayaalp" <self@gkayaalp.com>]

On 2017-10-12 15:58 +03, Eli Zaretskii <eliz@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?
>
> I don't know the answers, as I intentionally avoid using the system
> trash.
>

The Freedesktop spec [1] says (under "Contents of a trash directory"):

    A trash directory contains two subdirectories, named info and files.
    
    The $trash/files directory contains the files and directories that
    were trashed. When a file or directory is trashed, it MUST be moved
    into this directory5 . The names of files in this directory are to
    be determined by the implementation; the only limitation is that
    they must be unique within the directory. _Even if a file with the
    same name and location gets trashed many times, each subsequent
    trashing must not overwrite a previous copy (a)_. The access rights,
    access time, modification time and extended attributes (if any) for
    a file/directory in $trash/files SHOULD be the same as the
    file/directory had before getting trashed.
    
    IMPORTANT NOTE. While an implementation may choose to base filenames
    in the $trash/files directory on the original filenames, this is
    never to be taken for granted6. A filename in the $trash/files
    directory MUST NEVER be used to recover the original filename; use
    the info file (see below) for that. (If an info file corresponding
    to a file/directory in $trash/files is not available, this is an
    emergency case, and MUST be clearly presented as such to the user or
    to the system administrator).
    
    The $trash/info directory contains an “information file” for every
    file and directory in $trash/files. This file MUST have exactly the
    same name as the file or directory in $trash/files, plus the
    extension “.trashinfo”7.

It seems that the file name under <trash dir>/files/ is not important
and only an identifier, used to match the corresponding
<file name>.trashinfo file, which contains the path the file originally
was.  Thus, it should be possible to have that <file name> be a random
string with a sensible prefix (the name of the deleted file), allowing
to delete files at identical full-paths without trouble.  IMO we can
never know how important the files under the Trash/files directory might
or might not be, so it would be better to err on the safe side.

My trash can looks like this:

    /home/g/.local/share/Trash
    ├── files
    │   └── testdir
    └── info
        └── testdir.trashinfo

And info/testdir.trashinfo like this:

    [Trash Info]
    Path=/home/g/testdir
    DeletionDate=2017-10-12T15:01:27

I beleive the feature is useful, I myself do quite a bit of mistaken
deletings, and even though most of the more important stuff is version
controlled, things happen..

[1] https://specifications.freedesktop.org/trash-spec/trashspec-latest.html

-- 
İ. Göktuğ Kayaalp	<http://www.gkayaalp.com/>
			024C 30DD 597D 142B 49AC
			40EB 465C D949 B101 2427