thunar actions only on local drive

Bug #899624 reported by breek on 2011-12-03
78
This bug affects 17 people
Affects Status Importance Assigned to Milestone
thunar
Fix Released
Medium
thunar (Ubuntu)
Low
Unassigned

Bug Description

if i right-click files or folders on local drives i see default (open terminal) and custom thunar actions but when doing the same on samba shares (something like smb://192.168.1.111/mysambafolder) i see none of them.
the other stuff works as i can read and delete all my files on that network drive.

tested on ubuntu studio 11.10 with custom actions and on xubuntu 11.04 with no custom action added

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: thunar 1.2.3-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Sat Dec 3 16:28:38 2011
InstallationMedia: Ubuntu-Studio 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
ProcEnviron:
 PATH=(custom, user)
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: thunar
UpgradeStatus: No upgrade log present (probably fresh install)

Thunar skips user customizable actions on remote filesystems. However there's no real reason for this; the patch that does this is part of a five-year old commit. I suspect the reason is that this did not work with the old Thunar VFS, but it works fine now with GIO.

I'm attaching a patch which removes the local check.

Created attachment 3692
thunar-enable-remote-uca.patch

Extending UCA to other URI schemes is not as straight-forward as it seems.

Most custom actions do not support URIs yet. %u and %U are supported but not documented. This information needs to be added to the UCA edit dialog.

It is unclear whether we should expand %d, %D, %f and %F to URIs. Changing the behavior of these placeholders might break existing custom actions, so I think we have to introduce URI alternatives for %d and %D at least. This is even more important as some URIs and URI schemes cannot be converted to local paths, even if gvfs-fuse is available. So e.g. for some trash:// smb:// URIs (generally all URIs for which g_file_get_path() returns NULL), only custom actions that support URI parameters should be displayed.

*** Bug 7305 has been marked as a duplicate of this bug. ***

breek (breek) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed
Louis de Leseleuc (ldeleseleuc) wrote :

+1
Also custom - or even standard - Sento items are ignored.

Adam Bolte (boltronics) wrote :

Debian has the same issue, so the bug is likely upstream.

Changed in thunar (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Naumov Evgeny (nauevg) wrote :

xubuntu 12.04. bug is still exists

Tonny (tonnydourado) wrote :

Xubunt 14.04, bug still exists.

o0Dante0o (igorevi4-94) wrote :

archlinux, xfce 4.12, thunar 1.6.6. bug still exists :c

*** Bug 10635 has been marked as a duplicate of this bug. ***

*** Bug 7936 has been marked as a duplicate of this bug. ***

Changed in thunar:
importance: Unknown → Medium
status: Unknown → Confirmed

(In reply to Jérôme Guelfucci from comment #4)
> Patch proposed in a duplicate:
> https://bugzilla.xfce.org/attachment.cgi?id=3482&action=diff

I can confirm this patch as working.

+1, v1.6.3 (Debian Jessie)

PS: Thanks, Ambroz!!

The patch from some duplicate doesn't seem to work for me?

(In reply to Harald Judt from comment #10)
> The patch from some duplicate doesn't seem to work for me?

Hmm, weird. It works very well for me.

I just discovered a case that's not covered by this patch however. The "Image" tab in file properties of pictures is shown only for local files, even with the patch.

jvandenbroek (jvandenbroek) wrote :

Unfortunately it doesn't work here either after applying the above patch. It should be enough to only recompile Thunar and no other packages, right?

jvandenbroek (jvandenbroek) wrote :

Ah forget about above comment, the old libraries were still being used. I had to remove /usr/lib/i386-linux-gnu/thunarx-2 and link it to /usr/local/lib/thunarx-2, after which it works! Please make this upstream, it's a very simple solution.

any news on this? Xubuntu 16.04, bug still exists.

Gustavo Neves (guneves) wrote :

libthunarx-2-0_1.6.10-1~14.04_i386.deb patched - Linux Mint 17.3 Rosa XFCE 32-bit

Gustavo Neves (guneves) wrote :

I can confirm the fix still works, at least on Mint 17.3 Rosa XFCE 32-bit. I made some little converters actions that NEED to be used in network shares (and the desktop) and then I realised it would not work there.

Steps for people like me that would waste hours on this:
01. Enable source-code downloads on apt-sources (can be via gui)
02. sudo apt-get update
03. sudo build-deps thunar
04. mkdir $HOME/src && cd $HOME/src
05. apt-get source thunar
06. cd thunar-1.6.10
07. wget https://bugzilla.xfce.org/attachment.cgi?id=3482 -O patch3482.patch
08. try the patch: patch --dry-run -p1 < patch3482.patch
09. if no errors, run for real!
10. patch --dry-run -p1 < patch3482.patch &>/dev/null && patch -p1 < patch3482.patch || echo "Failed"
11. The usual way would be: ./configure + make + make install, but we know better, right?
12. Create deb packages: dpkg-buildpackage -rfakeroot -uc -b
13. If all went fone you will have 4 new .deb packages in $HOME/src (1 level above, cd ..)
14. I just double-clicked the file libthunarx-2-0_1.6.10-1~14.04_i386.deb and chose REINSTALL
15. Reboot (NEEDED) and it works
16. No need to reinstall the other packages

I created this on a virtual machine and deployed the .deb in 2 real machines with success. All of them Mint 17 Rosa XFCE 32-bit. If I can I will try to generate 64bit and Ubuntu debs as well, but someone else could use the setps above to do that.

I am attaching my .deb file here. But AGAIN: this is for Mint 17.3 Rosa XFCE 32-bit! Not sure it would work anywhere else and breaking thunar would be bad! In theory, should be fine for Ubuntu 14.04.5 (Trusty Tahr), BUT I HAVEN'T TESTED!

Main reason I am doing this is because this has been pending for years.

Gustavo Neves (guneves) wrote :

Hi again, I am really sorry to TRIPLE-POST, but I guess there is no remedy for that here.

My instructions above are kind of broken at some points and should be avoided, I can't really edit them.
I have created a Bash script that will automate the whole patch process in any debian-based distro.

XAP - XFCE Actions Patcher
https://github.com/tavinus/xap.sh

Tested on Xubuntu16 32bit, Xubuntu16 64bit, Ubuntu16+XFCE4 64bit, Mint17.3 32bit.
If you successfully run this somewhere else, please leave an issue on github telling me.

At this point I could post/host deb packages for all Ubuntu versions, but
it is probably safer to use xap.sh to generate at the target machine.

If anyone has suggestions to things I might be doing wrong there, please open an issue on github.
It would also be nice if someone can notify me when this finally gets applied upstream and xap.sh becomes irrelevant.

Cheers!
Gus

Changed in thunar:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.