From: Andrej N. Gritsenko <andrej@re...> - 2012-09-23 19:07:54
In gvfs-1.13.3 implemented a possibility to retrieve the real path to
the name so it now possible to open files in trash too. Unfortunately I
don't know if I can test gvfs version so the 'Open' still absent in the
file context menu despite it can be available. Do you have any solutions
With best wishes.
Leave this bug to me, please.
I already came up with a way to do it.
On Mon, Sep 24, 2012 at 3:07 AM, Andrej N. Gritsenko <andrej@...> wrote:
> In gvfs-1.13.3 implemented a possibility to retrieve the real path to
> the name so it now possible to open files in trash too. Unfortunately I
> don't know if I can test gvfs version so the 'Open' still absent in the
> file context menu despite it can be available. Do you have any solutions
> for this?
> With best wishes.
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> Pcmanfm-develop mailing list
From: Andrej N. Gritsenko <andrej@re...> - 2012-09-24 09:23:10
PCMan has written on Monday, 24 September, at 8:28:
>Leave this bug to me, please.
>I already came up with a way to do it.
The way which you've described in #3388692 will never work, I've
added a comment to it why it wouldn't: that is 'original path' which
you've described in ticket and that can be retrieved from GIO (that's
"trash::orig-path" attribute) but file doesn't exist in that place
anymore so that will not help. Real file is in .local/share/Trash, or
somedisk://.Trash-XXXXX, or somewhere else. Do you want to scan all of
mounted volumes for trash directories? It will mean exactly creating own
trash:// implementation or at least partially duplicate it. Another way
is to copy file from trash into some temp. directory then open it with
desired application but that is too dirty and inappropriate. And since
version 1.13.3 gvfs can give that real path out, the file can be opened
but before that version there is no clean way to open the file. And you
know, each mount or volume may contain own trash directory, whether the
trash:// URI contains files from all filesystems together. Until we
create own implementation of trash:// we have no legal way to know where
the file is in the filesystem (at least before 1.13.3 gvfs). I'm sorry.
I don't against to leave the bug to you, we just discuss it here,
aren't we? BTW, https://bugzilla.gnome.org/show_bug.cgi?id=667794 is in
GNOME bug tracker which is why they fixed it in gvfs 1.13.3.
With the best wishes.