GNU bug report logs -
#28792
26.0.60; Deleting to a custom trash directory in Dired gives error
Previous Next
Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>
Date: Thu, 12 Oct 2017 03:27:01 UTC
Severity: normal
Tags: fixed
Merged with 28519,
28828
Found in versions 26.0.50, 26.0.60, 27.0.50
Fixed in version 26.1
Done: Noam Postavsky <npostavs <at> users.sourceforge.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
On 2017-10-12 15:58 +03, 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?
>
> 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
This bug report was last modified 7 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.