Concerning delete-by-moving-to-trash on free systems

Concerning delete-by-moving-to-trash on free systems

[Tassilo Horn]

Hi all,

I've just found out about that option, and basically it's nice.  But in
order to integrate emacs on the modern GNU desktop the moving to trash
should be in compliance with the Freedesktop.org Trash Specification [1]
on systems that support it.  This spec enables undoing of deletions
which requires storage of some metadata of course.

Beside from not conforming to this standard, the current implementation
has other drawbacks.

  - Delete a directory foo which contains the files a and b recursively
    (from within dired).  Then goto the trash-directory.  Now foo, a and
    b are side by side.

  - Now delete another file named a.  This file is really deleted,
    because a already exists in trash.  (Overwriting would be as bad as
    the current decision.)

Bye,
Tassilo
__________
[1] http://www.freedesktop.org/wiki/Specifications/trash-spec?action=show&redirect=Standards%2Ftrash-spec

Re: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden]

Tassilo Horn wrote:
> Hi all,
> 
> I've just found out about that option, and basically it's nice.  But in
> order to integrate emacs on the modern GNU desktop the moving to trash
> should be in compliance with the Freedesktop.org Trash Specification [1]
> on systems that support it.  This spec enables undoing of deletions
> which requires storage of some metadata of course.
> 

FWIW, see #973 Support for moving files to freedesktop.org-style 
trashcan (with patch):
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=973

Re: Concerning delete-by-moving-to-trash on free systems

[martin rudalics]

 >   - Now delete another file named a.  This file is really deleted,
 >     because a already exists in trash.  (Overwriting would be as bad as
 >     the current decision.)

IMHO, this qualifies as a very severe bug.

martin

Re: Concerning delete-by-moving-to-trash on free systems

[Tassilo Horn]

David De La Harpe Golden <david@harpegolden.net> writes:

Hi David,

>> I've just found out about that option, and basically it's nice.  But
>> in order to integrate emacs on the modern GNU desktop the moving to
>> trash should be in compliance with the Freedesktop.org Trash
>> Specification [1] on systems that support it.  This spec enables
>> undoing of deletions which requires storage of some metadata of
>> course.
>>
>
> FWIW, see #973 Support for moving files to freedesktop.org-style
> trashcan (with patch):
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=973

Nice!  Why do you fallback to ~/.local/share/ in
move-file-to-trash-freedesktop.  With the predicate you already checked
that XDG_DATA_HOME is set.  If it's not set in
move-file-to-trash-freedesktop I'd expect an error.

Does that have a chance to be included for 23.1?  I know, it's
feature-freeze, but even if it wouldn't do TRT in each and every case,
it cannot be worse than the current behavior, right?

Bye,
Tassilo

Re: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden]

Tassilo Horn wrote:

> Nice!  Why do you fallback to ~/.local/share/ in
> move-file-to-trash-freedesktop.  With the predicate you already checked
> that XDG_DATA_HOME is set.  If it's not set in
> move-file-to-trash-freedesktop I'd expect an error.
> 

XDG_DATA_HOME is not guaranteed to be set in nonetheless freedesktop.org 
compliant environments (it's not set on my desktop running the 
generally-highly-fd.o XFCE4!):

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
| $XDG_DATA_HOME defines the base directory relative to which user
| specific data files should be stored. If $XDG_DATA_HOME is either not 
| set or empty, a default equal to $HOME/.local/share should be used.

So if it's not set, you're supposed to just go ahead and use the 
default.  It's just an override to allow people to use something other 
than .local/share if they want to.

Note the predicate didn't _only_ check if it's set,  that check is one 
part of a fast+loose "so, is this a freedesktop.org desktop where using 
this kind of trashcan would be appropriate" cascade of tests in
move-file-to-trash--freedesktop-p.

I figured having XDG_DATA_HOME was adequate to indicate a fd.o desktop,
but its absence does not mean a non-fd.o desktop.   I guess really, the 
fd.o model is apps decide to be partially or fully fd.o compliant, not 
that there's an easy way to check for fd.o-ness... but I might be wrong 
there:  If it's a thing that there's a more reliable way to tell "yes, 
nancy, this IS a freedesktop.org desktop", then
move-file-to-trash--freedesktop-p  could be simplified.

If it's actually okay for emacs to use the freedesktop-style trashcan by 
default rather than the builtin emacs "fallback" trashcan support, then 
the move-file-to-trash--freedesktop-p test could be dropped and the 
patch slightly simplified.

Note that it's really only one side of comprehensive trashcan support 
(the writing side). While it's not urgent (since most people interested 
in fd.o trashcans can presumably use their desktop environment file 
manager's trashcan interface), for the reading side, someone might 
conceivably want a dired that's trashcan-aware, so that you could browse 
the traschcan in a slightly extended dired view that offers a restore 
option (and at least with the metadata-available fd.o-style trashcan 
(and probably some others) it'd also be possible for dired to offer 
restorations of files when you're browsing a directory that has 
ex-members in the trashcan...).  That's generally more complicated e.g. 
while my patch for _writing_ to trashcan avails of the option not
to use per-volume trashcans in the relevant spec, _reading_ from trash 
properly should probably not disregard the existence of per-volume trash.

Re: Concerning delete-by-moving-to-trash on free systems

[Tassilo Horn]

David De La Harpe Golden <david@harpegolden.net> writes:

Hi!

>> Nice!  Why do you fallback to ~/.local/share/ in
>> move-file-to-trash-freedesktop.  With the predicate you already
>> checked that XDG_DATA_HOME is set.  If it's not set in
>> move-file-to-trash-freedesktop I'd expect an error.
>>
>
> XDG_DATA_HOME is not guaranteed to be set in nonetheless
> freedesktop.org compliant environments (it's not set on my desktop
> running the generally-highly-fd.o XFCE4!):

I see.  I looked at it too briefly.

> If it's actually okay for emacs to use the freedesktop-style trashcan
> by default rather than the builtin emacs "fallback" trashcan support,
> then the move-file-to-trash--freedesktop-p test could be dropped and
> the patch slightly simplified.

I'd say it's more than ok.  As I mentioned in my original posting the
current fallback trashcan loses data.  That's much more problematic than
moving the files to a real trash can which cannot be accessed
appropriately with emacs ATM.

> Note that it's really only one side of comprehensive trashcan support
> (the writing side).  While it's not urgent (since most people
> interested in fd.o trashcans can presumably use their desktop
> environment file manager's trashcan interface),

Exactly.  I like moving to trash because seldomly but sometimes I delete
something which I shouldn't delete.  The main point is that it's still
there, no matter if I have to fire up some other app to restore it.

> for the reading side, someone might conceivably want a dired that's
> trashcan-aware, so that you could browse the traschcan in a slightly
> extended dired view that offers a restore option (and at least with
> the metadata-available fd.o-style trashcan (and probably some others)
> it'd also be possible for dired to offer restorations of files when
> you're browsing a directory that has ex-members in the trashcan...).

That would be fantastic.

> That's generally more complicated e.g. while my patch for _writing_ to
> trashcan avails of the option not to use per-volume trashcans in the
> relevant spec, _reading_ from trash properly should probably not
> disregard the existence of per-volume trash.

Ok, let's add that to the 23.2 TODO list. ;-)

Anyway, my main point is (if I didn't mention it often enough): Don't
release 23.1 with an option which sounds great but loses data.

Bye,
Tassilo

Re: Concerning delete-by-moving-to-trash on free systems

[Juanma Barranquero]

On Thu, Nov 27, 2008 at 15:58, Tassilo Horn <tassilo@member.fsf.org> wrote:

> Anyway, my main point is (if I didn't mention it often enough): Don't
> release 23.1 with an option which sounds great but loses data.

File a bug report and mark it as "Severity: grave".

  Juanma

Re: Concerning delete-by-moving-to-trash on free systems

[Tassilo Horn]

"Juanma Barranquero" <lekktu@gmail.com> writes:

Hi Juanma,

>> Anyway, my main point is (if I didn't mention it often enough): Don't
>> release 23.1 with an option which sounds great but loses data.
>
> File a bug report and mark it as "Severity: grave".

Done, #1440.

Bye,
Tassilo

bug#1440: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden]

 > Delete a directory foo which contains the files a and b recursively
 > (from within dired).  Then goto the trash-directory.  Now foo, a and
 > b are side by side.

Not 100% sure, but one guess: maybe dired is itself recursing into the 
directory and deleting each file and then deleting the directory rather 
than deleting the directory as one operation, thus causing the flattening.


 > Now delete another file named a.  This file is really deleted,
 > because a already exists in trash.  (Overwriting would be as bad as
 > the current decision.)

Uh. Not that I'm a fan of the current builtin trashcan routine, but are 
you sure that it is actually losing data?

The current emacs move-file-to-trash _should_ be generating alternative 
in-trash names for files with clashing filenames with 
find-backup-file-name , see function body.

Some GUI file managers may be treating the generated names as
"hidden" backup files due to the naming scheme - can you verify you 
don't have "a.~1~" files in your ~/.Trash/ directory from the command 
line?  (My fd.o trashcan patch avoids using such filenames because turns 
out several GUI file managers actually choke on them (see patch 
commentary), btw, so if you've also adjusted your 
unpatched-with-my-patch-emacs trash-directory to point to the sepcial 
fd.o trashcan directory, then things will go, um, wronger.)

bug#1440: Concerning delete-by-moving-to-trash on free systems

[Tassilo Horn]

David De La Harpe Golden <david@harpegolden.net> writes:

>> Delete a directory foo which contains the files a and b recursively
>> (from within dired).  Then goto the trash-directory.  Now foo, a and
>> b are side by side.
>
> Not 100% sure, but one guess: maybe dired is itself recursing into the
> directory and deleting each file and then deleting the directory
> rather than deleting the directory as one operation, thus causing the
> flattening.

Yes, that's likely.  Anyway, I don't think that is what users would
expect and it makes recovery of deleted directories difficult.

>> Now delete another file named a.  This file is really deleted,
>> because a already exists in trash.  (Overwriting would be as bad as
>> the current decision.)
>
> Uh. Not that I'm a fan of the current builtin trashcan routine, but
> are you sure that it is actually losing data?
>
> The current emacs move-file-to-trash _should_ be generating
> alternative in-trash names for files with clashing filenames with
> find-backup-file-name, see function body.
>
> Some GUI file managers may be treating the generated names as "hidden"
> backup files due to the naming scheme

I use dired.

> - can you verify you don't have "a.~1~" files in your ~/.Trash/
> directory from the command line?

Yes.  But I have

,----[ C-h v backup-directory-alist RET ]
| backup-directory-alist is a variable defined in `files.el'.
| Its value is 
| ((".*" . "~/.backupFiles/"))
`----

and indeed, there are the backup files.  I'd propose to let-unbind
backup-directory-alist when making backups for deleted files.  They
always should be in .Trash.

Bye,
Tassilo

bug#1440: Concerning delete-by-moving-to-trash on free systems

[David De La Harpe Golden]

 > I'd propose to let-unbind backup-directory-alist when making backups
 > for deleted files.

That seems sensible/necessary.
Though I think that maybe backup and trashing code paths should just be 
decoupled to avoid ongoing problems - i.e. have  move-file-to-trash just 
not use find-backup-file-name. What happens when someone next changes 
the backup-file subsystem, or a user locally patches it?  fallback 
trashing silently breaks, of course, surprise! There's also the minor 
point that find-file-name handlers can't distinguish a fallback trash 
operation from a backup operation at present and might conceivably do 
the wrong thing.

And of course, all this is about fixing the fallback trashcan, which as 
already noted doesn't correspond to the free desktop trashcan. It 
probably isn't a proper  implementation of the macosx trashcan really 
either (should probably really be  using the relevant system trash api 
on that platform , which appears to be (though I'm not a  macosx 
programmer, just cursory google search) NSWorkspaceRecycleOperation  or 
maybe FSMoveObjectToTrashSync)