Hello!
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.
>Thanks
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.
Andriy.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
