GNU bug report logs - #60460
30.0.50; [FR] avoid putting remote files to local trash

Previous Next

Full log

View this message in rfc822 format

From: Ruijie Yu <ruijie <at> netyu.xyz>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "60460 <at> debbugs.gnu.org" <60460 <at> debbugs.gnu.org>
Subject: bug#60460: 30.0.50; [FR] avoid putting remote files to local trash
Date: Sun, 01 Jan 2023 10:47:37 -0600

Drew Adams <drew.adams <at> oracle.com> writes:

>> In response to this, I want to propose a change to the logic under which
>> trashing is performed rather than deletion.  However, I am not sure
>> which one of my following two ideas is more appropriate.
>>
>> 1. Allow the user to disable "moving to local trash" only for remote
>> files....
>> 2. Use a dedicated local trash directory for each remote, optionally
>> behind a toggle.
>
> (Caveat: I'm not knowledgeable about sending
> files to trash.)
>
> I would have thought that we already have a way
> for users to customize which files and dirs get
> sent to trash.
>
> Now I see that option `delete-by-moving-to-trash'
> is just a simple nil/t Boolean, as opposed to
> being nil (for don't trash) and non-nil for the
> possibility of filtering.
>
> Not trashing remote files is just one kind of
> filtering.  And you say that you want to do that
> in particular because some of your remote files
> are large.  Filtering out large files (local or
> remote) is another possibility (logically not
> the same as filtering out remote files).
>
> Users could have any number of criteria they
> want to use, to filter inclusion/exclusion of
> files to move to trash.
>
> Why not use a mechanism similar to what we use
> with `recentf.el'?  There, we have user option
> `recentf-exclude'.  That lets you use multiple
> regexps and predicates to specify the files
> you want to exclude from inclusion in the list
> of recent files.

Yes, that sounds like a good idea as well.  To expand on your idea, here
are my thoughts.

Similar to what we have for "recentf.el" today, we can have two
variables `delete-by-moving-to-trash-include' and
`delete-by-moving-to-trash-exclude', and make
`delete-by-moving-to-trash' a deprecated alias to
`delete-by-moving-to-trash-include'.  In this case, we can have the
following logic:

1. If both variables are nil, disable trashing;

2. If `dbmtt-include' is not a list, issue a warning (because now we
want a list) and enable universal trashing;

3. Handle predicates and regexps in `dbmtt-include' and `dbmtt-exclude'
similar to how these in `recentf-include' and `recentf-exclude' are
handled in "recentf.el".

One concern I have with this approach is the added complexity to file
deletion logic.  That is, whenever a file needs to be deleted with
trashing potential (TRASH is passed in as non-nil for the relevant
functions), the two lists need to be consulted for this file and all
predicates and regexps need to be run against its filename.

Best,


RY

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.