Your message dated Wed, 21 Oct 2015 02:26:11 +0200
with message-id <5626dba3.4090...@debian.org>
and subject line Re: regression in 2.46: can't restore a just-trashed file
has caused the Debian Bug report #800941,
regarding regression in 2.46: can't restore a just-trashed file
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
800941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: glib2.0
Version: 2.46.0-2
Severity: critical
Justification: breaks functionality of many file managers
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=749314
Control: tags -1 stretch sid upstream
Control: affects -1 caja nemo nautilus thunar
Steps to reproduce:
1. Move some file to trash using a file manager or gvfs-trash tool.
Tested with the following file managers: Caja, Nemo, Nautilus, Thunar.
2. Browse trash and try to restore the file.
The file manager complains that it can't determine the original location
of the file, and so doesn't restore it. This is a regression in 2.46 since
restoring worked fine in 2.44.
The problem is that "trash::orig-path" and "trash::deletion-date" attributes
are not added to the trashed file. Without that the file manager can't
determine the original location of the file, and hence can't restore it.
You can check the file attributes by printing the moved file's info:
gvfs-info trash:///file_name
Check the upstream report [1] for more details.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=749314
--- End Message ---
--- Begin Message ---
Version: 2.46.1-1
On Mon, 05 Oct 2015 11:53:38 +0300 =?UTF-8?B?VmxhZCBPcmxvdg==?=
<mon...@inbox.ru> wrote:
> Source: glib2.0
> Version: 2.46.0-2
> Severity: critical
> Justification: breaks functionality of many file managers
>
> Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=749314
> Control: tags -1 stretch sid upstream
> Control: affects -1 caja nemo nautilus thunar
>
>
> Steps to reproduce:
> 1. Move some file to trash using a file manager or gvfs-trash tool.
> Tested with the following file managers: Caja, Nemo, Nautilus, Thunar.
> 2. Browse trash and try to restore the file.
>
> The file manager complains that it can't determine the original location
> of the file, and so doesn't restore it. This is a regression in 2.46 since
> restoring worked fine in 2.44.
>
> The problem is that "trash::orig-path" and "trash::deletion-date" attributes
> are not added to the trashed file. Without that the file manager can't
> determine the original location of the file, and hence can't restore it.
>
> You can check the file attributes by printing the moved file's info:
> gvfs-info trash:///file_name
>
> Check the upstream report [1] for more details.
>
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=749314
This was fixed in 2.46.1 by commit
0aae1bf g_local_file_trash: write info file first
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
