bug#33336: 26; Document how to restore trashed files

bug#33336: 26; Document how to restore trashed files

[Drew Adams]

I tried to answer this question, knowing nothing about trashed files:
https://emacs.stackexchange.com/q/37492/105

I can understand that if files are trashed to the system recycle bin
then perhaps Emacs cannot help users much in telling them how to restore
trashed files (or can it?).

But if `trash-directory' is non-nil then can't (and shouldn't) Emacs
tell users how to restore files trashed there?  Is there an Emacs
operation that does this?  If not, can a user just move a file from that
directory to another (IOW, are trashed files normal files)?  And is
there some way for a user to know what the original location was for a
trashed file?

In sum, is there something that Emacs can offer users, in terms of
helping them restore trashed files?


In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor `Microsoft Corp.', version 10.0.16299
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#33336: 26; Document how to restore trashed files

[Eli Zaretskii]

> Date: Sat, 10 Nov 2018 11:31:48 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> I tried to answer this question, knowing nothing about trashed files:
> https://emacs.stackexchange.com/q/37492/105

I don't think your answer is correct, not on Windows anyway.

> I can understand that if files are trashed to the system recycle bin
> then perhaps Emacs cannot help users much in telling them how to restore
> trashed files (or can it?).
> 
> But if `trash-directory' is non-nil then can't (and shouldn't) Emacs
> tell users how to restore files trashed there?  Is there an Emacs
> operation that does this?  If not, can a user just move a file from that
> directory to another (IOW, are trashed files normal files)?  And is
> there some way for a user to know what the original location was for a
> trashed file?
> 
> In sum, is there something that Emacs can offer users, in terms of
> helping them restore trashed files?

This is a system facility, Emacs just uses it.  Restoring files from
there is something specific to each system, and is not for Emacs to
provide or document.

So I don't think we should do anything with this.  Users should read
their OS documentation about this.

bug#33336: 26; Document how to restore trashed files

[Glenn Morris]

Eli Zaretskii wrote:

> This is a system facility, Emacs just uses it.  Restoring files from
> there is something specific to each system, and is not for Emacs to
> provide or document.

I don't see how moving something out of trash is different to moving it
in this regard.

On GNU systems, the only relevant mechanism is the freedesktop trash
spec that move-file-to-trash implements. It looks like it would be
straightforward for someone who wanted to to write a
move-file-from-trash that restores files according to the trashinfo
file, and this could be hooked into dired.

bug#33336: 26; Document how to restore trashed files

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Drew Adams <drew.adams@oracle.com>,  33336@debbugs.gnu.org
> Date: Sat, 10 Nov 2018 16:26:07 -0500
> 
> Eli Zaretskii wrote:
> 
> > This is a system facility, Emacs just uses it.  Restoring files from
> > there is something specific to each system, and is not for Emacs to
> > provide or document.
> 
> I don't see how moving something out of trash is different to moving it
> in this regard.

Where trash is just another directory, you are right.  But that's just
one variety.

> On GNU systems, the only relevant mechanism is the freedesktop trash
> spec that move-file-to-trash implements. It looks like it would be
> straightforward for someone who wanted to to write a
> move-file-from-trash that restores files according to the trashinfo
> file, and this could be hooked into dired.

This won't work on MS-Windows, where trash is a special directory, and
restoring files from there is a special operation, not just moving a
file.

bug#33336: 26; Document how to restore trashed files

[Eli Zaretskii]

> Date: Sun, 11 Nov 2018 05:35:18 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 33336@debbugs.gnu.org
> 
> > From: Glenn Morris <rgm@gnu.org>
> > Cc: Drew Adams <drew.adams@oracle.com>,  33336@debbugs.gnu.org
> > Date: Sat, 10 Nov 2018 16:26:07 -0500
> > 
> > Eli Zaretskii wrote:
> > 
> > > This is a system facility, Emacs just uses it.  Restoring files from
> > > there is something specific to each system, and is not for Emacs to
> > > provide or document.
> > 
> > I don't see how moving something out of trash is different to moving it
> > in this regard.
> 
> Where trash is just another directory, you are right.  But that's just
> one variety.

Actually, I take that back: even if trash is a directory that uses the
freedesktop trash spec, undeleting a file via Dired is not entirely
straightforward, for at least two reasons:

  . Dired is based on parsing the output of 'ls', and AFAIK GNU 'ls'
    isn't yet capable of displaying trash directories in useful,
    human-readable ways (we'd probably need to reuse/reinvent portions
    of ls-lisp?)
  . Trash directories routinely have several versions of the same
    file, and AFAIK Dired doesn't have capabilities for presenting
    several versions of the same file in a way that would facilitate
    the decision whether and which version to restore

bug#33336: 26; Document how to restore trashed files

[Drew Adams]

> > Where trash is just another directory, you are right.  But that's
> > just one variety.
> 
> Actually, I take that back: even if trash is a directory that uses the
> freedesktop trash spec, undeleting a file via Dired is not entirely
> straightforward, for at least two reasons:
> 
>   . Dired is based on parsing the output of 'ls', and AFAIK GNU 'ls'
>     isn't yet capable of displaying trash directories in useful,
>     human-readable ways (we'd probably need to reuse/reinvent portions
>     of ls-lisp?)
>   . Trash directories routinely have several versions of the same
>     file, and AFAIK Dired doesn't have capabilities for presenting
>     several versions of the same file in a way that would facilitate
>     the decision whether and which version to restore

But "just another directory" is more general than "directory
that uses the freedesktop trash spec".  At least if it is
an ordinary ("just another") directory, and not a directory
that uses the freedesktop trash spec, can't we help users
wrt restoring files parked there?

bug#33336: 26; Document how to restore trashed files

[Eli Zaretskii]

> Date: Sun, 11 Nov 2018 08:52:51 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 33336@debbugs.gnu.org
> 
> > > Where trash is just another directory, you are right.  But that's
> > > just one variety.
> > 
> > Actually, I take that back: even if trash is a directory that uses the
> > freedesktop trash spec, undeleting a file via Dired is not entirely
> > straightforward, for at least two reasons:
> > 
> >   . Dired is based on parsing the output of 'ls', and AFAIK GNU 'ls'
> >     isn't yet capable of displaying trash directories in useful,
> >     human-readable ways (we'd probably need to reuse/reinvent portions
> >     of ls-lisp?)
> >   . Trash directories routinely have several versions of the same
> >     file, and AFAIK Dired doesn't have capabilities for presenting
> >     several versions of the same file in a way that would facilitate
> >     the decision whether and which version to restore
> 
> But "just another directory" is more general than "directory
> that uses the freedesktop trash spec".  At least if it is
> an ordinary ("just another") directory, and not a directory
> that uses the freedesktop trash spec, can't we help users
> wrt restoring files parked there?

I don't know.  I have no idea who would use that option.  I presume
the vast majority leave the default nil setting of trash-directory
intact, and get the freedesktop style trash (and the Recycle Bin on
Windows).  I see no reason to have a feature that is useful for a tiny
minority of users, while the bulk of them need to use system tools
instead.  Besides, if trash-directory is a simple directory, do we
really need to tell users how to move files out of there?

Sorry, makes no sense to me.

bug#33336: 26; Document how to restore trashed files

[Drew Adams]

> > > This is a system facility, Emacs just uses it.  Restoring files
> from
> > > there is something specific to each system, and is not for Emacs to
> > > provide or document.
> >
> > I don't see how moving something out of trash is different to moving
> it
> > in this regard.
> 
> Where trash is just another directory, you are right.  But that's just
> one variety.
> 
> > On GNU systems, the only relevant mechanism is the freedesktop trash
> > spec that move-file-to-trash implements. It looks like it would be
> > straightforward for someone who wanted to to write a
> > move-file-from-trash that restores files according to the trashinfo
> > file, and this could be hooked into dired.
> 
> This won't work on MS-Windows, where trash is a special directory, and
> restoring files from there is a special operation, not just moving a
> file.

I addressed this possibility at the outset:

  I can understand that if files are trashed to the system
  recycle bin then perhaps Emacs cannot help users much in
  telling them how to restore trashed files (or can it?).

The bug report asks that we do what we can to help users
in the cases where we can.

  But if `trash-directory' is non-nil then can't (and shouldn't)
  Emacs tell users how to restore files trashed there?

Presumably (?) `trash-directory' is "just another directory".
That's the case (at least) where I was thinking that Emacs
should be able to help.  I was thinking that in this case, at
least, restoring a file from there should be "just moving a file".

But this would presumably require recording the original
directory, to where each file should be restored (by default).
And the "restoring" code would need to, e.g., prompt the user
for some alternative directory if the recorded directory no
longer existed.

The Emacs doc for this can make clear that Emacs may not
be able to help in some cases where the system trash bin
is used, and in such cases users should consult their
system doc for how to restore a file. 

To repeat the last line of the bug report:

  In sum, is there something that Emacs can offer users,
                   ^^^^^^^^^
  in terms of helping them restore trashed files?

bug#33336: 26; Document how to restore trashed files

[Eli Zaretskii]

> Date: Sun, 11 Nov 2018 08:47:28 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: drew.adams@oracle.com, 33336@debbugs.gnu.org
> 
> But this would presumably require recording the original
> directory, to where each file should be restored (by default).
> And the "restoring" code would need to, e.g., prompt the user
> for some alternative directory if the recorded directory no
> longer existed.

That's exactly what the freedesktop spec does, and the side effect is
that the files in the trash don't have their original names.

> The Emacs doc for this can make clear that Emacs may not
> be able to help in some cases where the system trash bin
> is used, and in such cases users should consult their
> system doc for how to restore a file. 

I added there yesterday a sentence saying that restoring files from
trash needs system-dependent tools.  I don't think we need to do more.

bug#33336: 26; Document how to restore trashed files

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a system facility, Emacs just uses it.  Restoring files from
> there is something specific to each system, and is not for Emacs to
> provide or document.
>
> So I don't think we should do anything with this.  Users should read
> their OS documentation about this.

I think this was the conclusion here, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no