From: "Göktuğ Kayaalp" <self@gkayaalp.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: kaushal.modi@gmail.com, eggert@cs.ucla.edu, 28792@debbugs.gnu.org
Subject: bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error
Date: Thu, 12 Oct 2017 16:37:26 +0300 [thread overview]
Message-ID: <ygm8tggbi7d.fsf@gkayaalp.com> (raw)
In-Reply-To: <831sm8mskc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 12 Oct 2017 15:58:11 +0300")
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
next prev parent reply other threads:[~2017-10-12 13:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 3:26 bug#28792: 26.0.60; Deleting to a custom trash directory in Dired gives error Kaushal Modi
2017-10-12 3:36 ` Kaushal Modi
2017-10-12 3:51 ` Kaushal Modi
2017-10-12 12:50 ` Göktuğ Kayaalp
2017-10-12 12:58 ` Eli Zaretskii
2017-10-12 13:02 ` Kaushal Modi
2017-10-12 13:37 ` Göktuğ Kayaalp [this message]
2017-10-12 12:58 ` Kaushal Modi
2017-10-12 13:16 ` Eli Zaretskii
2017-10-12 13:31 ` Kaushal Modi
2017-10-12 13:44 ` Eli Zaretskii
2017-10-12 14:02 ` Andreas Schwab
2017-10-12 14:06 ` Kaushal Modi
2017-10-12 15:07 ` Kaushal Modi
2017-10-12 15:15 ` Eli Zaretskii
2017-10-12 15:27 ` Andreas Schwab
2017-10-12 15:31 ` Kaushal Modi
2017-10-12 20:25 ` Paul Eggert
2017-10-12 21:41 ` Kaushal Modi
2017-10-15 7:18 ` Paul Eggert
2017-10-15 13:35 ` Kaushal Modi
2017-10-15 13:47 ` Noam Postavsky
2017-10-12 14:24 ` Noam Postavsky
2017-10-12 14:43 ` Drew Adams
2017-10-12 15:07 ` Andreas Schwab
2017-10-12 15:10 ` Drew Adams
2017-10-12 13:34 ` Tino Calancha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ygm8tggbi7d.fsf@gkayaalp.com \
--to=self@gkayaalp.com \
--cc=28792@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=kaushal.modi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.