GNU bug report logs -
#44059
28.0.50; Trash files cannot be deleted properly if delete-by-moving-to-trash is set
Previous Next
Reported by: Jean Louis <bugs <at> gnu.support>
Date: Sun, 18 Oct 2020 09:29:02 UTC
Severity: minor
Found in version 28.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44059 in the body.
You can then email your comments to 44059 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Sun, 18 Oct 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jean Louis <bugs <at> gnu.support>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 18 Oct 2020 09:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
If I set:
trash-directory and delete-by-moving-to-trash
then I cannot delete files in Trash, you can see what is happening,
files may get a backup in Trash directory, but they do not get deleted,
I need to invoke shell command or disable delete-by-moving-to-trash
Best would be when first file is placed into Trash, that Emacs places
there some directory local variable that would disable
delete-by-moving-to-trash when deleting in that directory
In GNU Emacs 28.0.50 (build 18, x86_64-pc-linux-gnu, GTK+ Version 3.22.12, cairo version 1.14.8)
of 2020-10-14 built on protected.rcdrun.com
Repository revision: 423439b38067c4a428310edab24fba7da082027c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11907000
System Description: Hyperbola GNU/Linux-libre
Configured using:
'configure --prefix=/package/text/emacs-2020-10-14 --with-modules'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS JSON PDUMPER LCMS2
Important settings:
value of $LC_ALL: de_DE.UTF-8
value of $LANG: de_DE.UTF-8
value of $XMODIFIERS: @im=exwm-xim
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort hashcash mail-extr emacsbug message rmc puny rfc822 mml
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
auth-source eieio eieio-core cl-macs eieio-loaddefs password-cache json
map text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rect delsel cl-seq
image-mode exif vc-git diff-mode easy-mmode view misearch multi-isearch
dired-aux dired dired-loaddefs cus-edit cus-start cus-load wid-edit
cl-extra seq byte-opt gv bytecomp byte-compile cconv cl-print thingatpt
help-fns radix-tree help-mode easymenu cl-loaddefs cl-lib tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 107871 10426)
(symbols 48 9849 1)
(strings 32 29033 2153)
(string-bytes 1 849511)
(vectors 16 15242)
(vector-slots 8 198702 11716)
(floats 8 56 149)
(intervals 56 4869 4)
(buffers 992 20))
--
Thanks,
Jean Louis
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Sun, 18 Oct 2020 09:33:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44059 <at> debbugs.gnu.org (full text, mbox):
Maybe is better to set dir-locals-set-class-variables for the Trash
directory, so that delete-by-moving-to-trash is unset there, if that
is possible.
Another method of specifying directory-local variables is to define a
group of variables/value pairs in a “directory class”, using the
‘dir-locals-set-class-variables’ function; then, tell Emacs which
directories correspond to the class by using the
‘dir-locals-set-directory-class’ function. These function calls
normally go in your initialization file (*note Init File::). This
method is useful when you can’t put ‘.dir-locals.el’ in a directory for
some reason. For example, you could apply settings to an unwritable
directory this way:
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 19 Oct 2020 09:55:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 44059 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> then I cannot delete files in Trash, you can see what is happening,
> files may get a backup in Trash directory, but they do not get deleted,
> I need to invoke shell command or disable delete-by-moving-to-trash
I'm not sure whether that's a malfeature or not -- if you've told Emacs
that everything you delete should go to the trash can, then even
deleting things in the trash can should perhaps go there?
Perhaps a new value to delete-by-moving-to-trash that would mean "delete
if we're trying to delete in the trash can"?
And... there doesn't seem to be any commands in Emacs for emptying the
trash can? Shouldn't there be?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 19 Oct 2020 11:31:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 44059 <at> debbugs.gnu.org (full text, mbox):
* Lars Ingebrigtsen <larsi <at> gnus.org> [2020-10-19 12:55]:
> Jean Louis <bugs <at> gnu.support> writes:
>
> > then I cannot delete files in Trash, you can see what is happening,
> > files may get a backup in Trash directory, but they do not get deleted,
> > I need to invoke shell command or disable delete-by-moving-to-trash
>
> I'm not sure whether that's a malfeature or not -- if you've told Emacs
> that everything you delete should go to the trash can, then even
> deleting things in the trash can should perhaps go there?
>
> Perhaps a new value to delete-by-moving-to-trash that would mean "delete
> if we're trying to delete in the trash can"?
>
> And... there doesn't seem to be any commands in Emacs for emptying the
> trash can? Shouldn't there be?
I think that is related to Dired and maybe some functions without
Dired.
I have solved the problem by adding in ~/tmp/Trash/.dir-locals.el
;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")
((dired-mode . ((delete-by-moving-to-trash . nil))))
In my opinion, if the delete-by-moving-to-trash is true, that file
should be made there read-only and user should be informed in Info
manual or in the setting of that variable including setting of
variable for trash location.
Practical error case is that I was recording screen and deleting
various videos, screen recording was taking so much space, I lost all
space on hard disk. And I could not delete things inside of the
Trash. It was emergency already to do something, my solution was
above.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 19 Oct 2020 14:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 44059 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 19 Oct 2020 11:54:30 +0200
> Cc: 44059 <at> debbugs.gnu.org
>
> And... there doesn't seem to be any commands in Emacs for emptying the
> trash can? Shouldn't there be?
AFAIU, doing this for freedesktop-style trash isn't trivial.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 19 Oct 2020 15:14:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44059 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> And... there doesn't seem to be any commands in Emacs for emptying the
>> trash can? Shouldn't there be?
>
> AFAIU, doing this for freedesktop-style trash isn't trivial.
Isn't there some external command we could run? From a quick look at my
system maybe "gio trash --empty"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 26 Oct 2020 19:30:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44059 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-10-19 17:55]:
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Mon, 19 Oct 2020 11:54:30 +0200
> > Cc: 44059 <at> debbugs.gnu.org
> >
> > And... there doesn't seem to be any commands in Emacs for emptying the
> > trash can? Shouldn't there be?
>
> AFAIU, doing this for freedesktop-style trash isn't trivial.
Actually it says that Emacs already does that:
Hide Trash Directory: Value Menu Directory: /home/data1/protected/tmp/Trash/
State : SAVED and set.
Directory for ‘move-file-to-trash’ to move files and directories to. Hide
This directory is used only when the function ‘system-move-file-to-trash’
is not defined.
Relative paths are interpreted relative to ‘default-directory’.
If the value is nil, Emacs uses a freedesktop.org-style trashcan.
So if I set the variable: delete-by-moving-to-trash and not set
trash-directory it will use freedeskstop style. I did not verify, I
just assume it.
There is no big problem. If delete-by-moving-to-trash is set then
Tramp says it was trashed, which is confusing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 26 Oct 2020 19:45:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 44059 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 26 Oct 2020 19:03:22 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44059 <at> debbugs.gnu.org
>
> * Eli Zaretskii <eliz <at> gnu.org> [2020-10-19 17:55]:
> > > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > > Date: Mon, 19 Oct 2020 11:54:30 +0200
> > > Cc: 44059 <at> debbugs.gnu.org
> > >
> > > And... there doesn't seem to be any commands in Emacs for emptying the
> > > trash can? Shouldn't there be?
> >
> > AFAIU, doing this for freedesktop-style trash isn't trivial.
>
> Actually it says that Emacs already does that:
It does?
> Hide Trash Directory: Value Menu Directory: /home/data1/protected/tmp/Trash/
> State : SAVED and set.
> Directory for ‘move-file-to-trash’ to move files and directories to. Hide
> This directory is used only when the function ‘system-move-file-to-trash’
> is not defined.
> Relative paths are interpreted relative to ‘default-directory’.
> If the value is nil, Emacs uses a freedesktop.org-style trashcan.
>
> So if I set the variable: delete-by-moving-to-trash and not set
> trash-directory it will use freedeskstop style.
Look above: we were talking about _emptying_ the trashcan, not about
_using_ it to move deleted files there.
> There is no big problem. If delete-by-moving-to-trash is set then
> Tramp says it was trashed, which is confusing.
And this is yet another, almost unrelated, issue.
Can we please stay focused in each thread on the topic of that thread,
and nothing more?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Mon, 26 Oct 2020 20:08:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 44059 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> There is no big problem. If delete-by-moving-to-trash is set then
> Tramp says it was trashed, which is confusing.
No. Tramp doesn't say this. This message comes from dired.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Wed, 28 Oct 2020 11:43:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 44059 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-10-26 22:44]:
> > There is no big problem. If delete-by-moving-to-trash is set then
> > Tramp says it was trashed, which is confusing.
>
> And this is yet another, almost unrelated, issue.
>
> Can we please stay focused in each thread on the topic of that thread,
> and nothing more?
Actually exactly that was my intended original message for this
bug. That variable should not affect remote systems and Tramp should
not assume neither seek remote trash if that variable is set, it
should remain local.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Wed, 28 Oct 2020 15:37:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 44059 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 28 Oct 2020 14:42:49 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: larsi <at> gnus.org, 44059 <at> debbugs.gnu.org
>
> Actually exactly that was my intended original message for this
> bug. That variable should not affect remote systems and Tramp should
> not assume neither seek remote trash if that variable is set, it
> should remain local.
I don't think I agree with your categorical opinion on tis.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Wed, 28 Oct 2020 17:40:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 44059 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-10-28 18:36]:
> > Date: Wed, 28 Oct 2020 14:42:49 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: larsi <at> gnus.org, 44059 <at> debbugs.gnu.org
> >
> > Actually exactly that was my intended original message for this
> > bug. That variable should not affect remote systems and Tramp should
> > not assume neither seek remote trash if that variable is set, it
> > should remain local.
>
> I don't think I agree with your categorical opinion on tis.
Maybe it sounds too strict. I am always fine with whatever final
decisions you as group make in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44059
; Package
emacs
.
(Sat, 12 Feb 2022 08:06:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 44059 <at> debbugs.gnu.org (full text, mbox):
Jean Louis <bugs <at> gnu.support> writes:
> I have solved the problem by adding in ~/tmp/Trash/.dir-locals.el
>
> ;;; Directory Local Variables
> ;;; For more information see (info "(emacs) Directory Variables")
>
> ((dired-mode . ((delete-by-moving-to-trash . nil))))
I've now added this to the manual in Emacs 29, and I think that should
be sufficient.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug marked as fixed in version 29.1, send any further explanations to
44059 <at> debbugs.gnu.org and Jean Louis <bugs <at> gnu.support>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 12 Feb 2022 08:06:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 12 Mar 2022 12:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 103 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.