From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?G=C3=B6ktu=C4=9F?= Kayaalp Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <831sm8mskc.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1507816163 15708 195.159.176.226 (12 Oct 2017 13:49:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Oct 2017 13:49:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: kaushal.modi@gmail.com, eggert@cs.ucla.edu, 28792@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 12 15:49:17 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2drO-0003Aw-Up for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Oct 2017 15:49:15 +0200 Original-Received: from localhost ([::1]:45669 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2drW-0007Mx-GT for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Oct 2017 09:49:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53809) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2dgf-0006r9-5Y for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:38:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2dgZ-0003b5-Bm for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:38:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54595) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e2dgZ-0003at-5z for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:38:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e2dgY-0007hR-TC for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?G=C3=B6ktu=C4=9F?= Kayaalp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 13:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28792 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28792-submit@debbugs.gnu.org id=B28792.150781545229545 (code B ref 28792); Thu, 12 Oct 2017 13:38:02 +0000 Original-Received: (at 28792) by debbugs.gnu.org; 12 Oct 2017 13:37:32 +0000 Original-Received: from localhost ([127.0.0.1]:35042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dg3-0007gT-QJ for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:37:32 -0400 Original-Received: from relay2-d.mail.gandi.net ([217.70.183.194]:32769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dg2-0007gL-2V for 28792@debbugs.gnu.org; Thu, 12 Oct 2017 09:37:30 -0400 X-Originating-IP: 188.3.108.78 Original-Received: from alpha.alpha (unknown [188.3.108.78]) (Authenticated sender: self@gkayaalp.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 41EE7C5A80; Thu, 12 Oct 2017 15:37:27 +0200 (CEST) In-Reply-To: <831sm8mskc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 12 Oct 2017 15:58:11 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138279 Archived-At: On 2017-10-12 15:58 +03, Eli Zaretskii 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. =20=20=20=20 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. =20=20=20=20 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). =20=20=20=20 The $trash/info directory contains an =E2=80=9Cinformation file=E2=80= =9D 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 =E2=80=9C.trashinfo=E2=80=9D7. It seems that the file name under /files/ is not important and only an identifier, used to match the corresponding .trashinfo file, which contains the path the file originally was. Thus, it should be possible to have that 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 =E2=94=9C=E2=94=80=E2=94=80 files =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 testdir =E2=94=94=E2=94=80=E2=94=80 info =E2=94=94=E2=94=80=E2=94=80 testdir.trashinfo And info/testdir.trashinfo like this: [Trash Info] Path=3D/home/g/testdir DeletionDate=3D2017-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 --=20 =C4=B0. G=C3=B6ktu=C4=9F Kayaalp 024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427