Thunar 1.6.4 crashes when copying files

GWR · 2015-03-05 15:53:54

My VM is now installed:
- Linux Mint 17.1 (RC) 64 Bit "Rebecca"
- installed in a VM on VirtualBox
- updated/upgraded everything after fresh install
- "sudo add-apt-repository ppa:xubuntu-dev/xfce-4.12 -y && sudo apt-get update && sudo apt-get dist-upgrade -y"

Thunar does not crash - but interestingly correctly refreshes the moved file:
- move from home/user/A/file.txt to home/user/B/file.txt
- when clicking on directory "B" the file is there after the moving action, on my local computer I have to refresh the list to see the file - this was not the way in older versions.
- in the VM it does not refresh when moving a file to a samba share

Will install Linux Mint 17 "Qiana" now.

Edit: Installed Mint 17 "Qiana" now.
Updated it exactly the same as described above. Until now I could not crash thunar, but the movement is bugged compared to "Rebecca" - Moving a file and then switching into this target directory does not show up the file until I refresh the view.

So it seems that there is something else missing to make it segfault - another tool, some symlinks or whatever. Thought the straces will already show at which portion it crashes - so it should be tackleable by some more verbose debug builds.

Running thunar from console does not emit bugs as it has done before (but this isnt the case for my local computer too - prior I got asserts like others described in the bug reports already).

bye
Ron

Last edited by GWR (2015-03-05 17:24:45)

ToZ · 2015-03-05 18:46:52

A good test to prove what you've stated before - that there is another piece in this puzzle.

As for the file refresh issue, have a look at this related threaad. It links to some bug reports. Also, it looks like the bug was fixed in Thunar 1.6.5.

As for the Samba share refresh, how are you connecting to the share? I find that if I use cifs (mount, autofs) it refreshed fine. However, if I use gvfs (gigolo or smb:// from inside Thunar), I don't get the refresh. I wonder if its an issue with gvfs remote file monitoring.

GWR · 2015-03-05 22:26:19

I use gvfs for my samba shares.

@"related thread"
A normal "F5" fixes the display.
When moving a file from "somewhere" to "/home/bla/Desktop" while having a "windowed" thunar (means you see the desktop) you see the file being placed on the desktop while the thunar window does not show this entry until switching to another directory and back - or pressing F5/reload.

@puzzle
I assume that some of the libs are different and therefore some kind of "chain" is broken which then leads to a null/nil value somewhere. Thought "straces" will help in exactly that case (think there is not much of threading and concurrency happen in this situation) helping to narrowing down things.

Do you happen to know a command to have some kind of "lib comparison" so I could check differences between my local computer and the VM ?

bye
Ron

rworkman · 2015-03-06 06:09:09

I set up a VM of Slackware 14.1, which has dbus-1.6.12, and did some tests in an attempt to figure out what was going on. It looks like a bugfix in 1.6.14 makes the copy/paste crash go away for me (as noted in https://bugzilla.xfce.org/show_bug.cgi?id=11450#c65 ). However, Kevin Fenzi of Fedora states in https://bugzilla.xfce.org/show_bug.cgi?id=11450#c5 that users of Fedora 20 (with dbus-1.6.28) are also seeing this bug, so I'm not sure. Perhaps there's a problem with the F20 package, or perhaps a regression in later dbus-1.6.x releases, or perhaps something else entirely, but some testing/confirmation would be appreciated.

ToZ · 2015-03-06 11:28:52

GWR wrote:

Do you happen to know a command to have some kind of "lib comparison" so I could check differences between my local computer and the VM ?

Try:

ldd $(which thunar)

...to see a complete list of libraries and versions that thunar is linked to. Compare the results between the two systems.

GWR · 2015-03-06 13:21:21

Thanks, for now I used to use "ldd /usr/bin/thunar" - which does the same job.

Ok. Except memory address variants (of course) there is one library linked on my local computer, which is NOT linked on the VM:

	libxfce4util.so.6 => /usr/lib/x86_64-linux-gnu/libxfce4util.so.6 (0x00007f9439c34000)

How could that be? Both variants are obviously from the "ppa"-repo?

VM:

 $ apt-cache policy thunar
thunar:
  Installiert:           1.6.6-0ubuntu1~14.04
  Installationskandidat: 1.6.6-0ubuntu1~14.04
  Versionstabelle:
 *** 1.6.6-0ubuntu1~14.04 0
        500 http://ppa.launchpad.net/xubuntu-dev/xfce-4.12/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status
     1.6.3-1ubuntu5 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages

Local:

$ apt-cache policy thunar
thunar:
  Installiert:           1.6.6-0ubuntu1~14.04
  Installationskandidat: 1.6.6-0ubuntu1~14.04
  Versionstabelle:
 *** 1.6.6-0ubuntu1~14.04 0
        500 http://ppa.launchpad.net/xubuntu-dev/xfce-4.12/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status
     1.6.3-1ubuntu5 0
        500 http://ftp-stud.hs-esslingen.de/ubuntu/ trusty/universe amd64 Packages

(I use another url for normal packages to get my packages with >10MB/s).

EDIT: on Mint 17.1 "Rebecca" the lib "libxfce4util.so.6" isnt linked too. So only my local machine... hmm.

EDIT2: To be able to compare on your own:

$ ldd $(which thunar)
	linux-vdso.so.1 =>  (0x00007fff5d3fe000)
	libthunarx-2.so.0 => /usr/lib/x86_64-linux-gnu/libthunarx-2.so.0 (0x00007f943d9df000)
	libexo-1.so.0 => /usr/lib/x86_64-linux-gnu/libexo-1.so.0 (0x00007f943d794000)
	libgudev-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0 (0x00007f943d589000)
	libnotify.so.4 => /usr/lib/x86_64-linux-gnu/libnotify.so.4 (0x00007f943d381000)
	libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f943d179000)
	libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f943cf5c000)
	libxfce4ui-1.so.0 => /usr/lib/x86_64-linux-gnu/libxfce4ui-1.so.0 (0x00007f943cd48000)
	libgtk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f943c70c000)
	libxfce4util.so.7 => /usr/lib/x86_64-linux-gnu/libxfce4util.so.7 (0x00007f943c4fc000)
	libgdk-x11-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007f943c24a000)
	libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f943c028000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f943be06000)
	libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 (0x00007f943bafb000)
	libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f943b8ae000)
	libxfconf-0.so.2 => /usr/lib/x86_64-linux-gnu/libxfconf-0.so.2 (0x00007f943b69a000)
	libdbus-glib-1.so.2 => /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x00007f943b473000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f943b22e000)
	libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f943aeba000)
	libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f943ac69000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f943a961000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f943a742000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f943a37d000)
	libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f943a179000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f9439e43000)
	libxfce4util.so.6 => /usr/lib/x86_64-linux-gnu/libxfce4util.so.6 (0x00007f9439c34000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f943992e000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f943971c000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f9439517000)
	libstartup-notification-1.so.0 => /usr/lib/x86_64-linux-gnu/libstartup-notification-1.so.0 (0x00007f943930d000)
	libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f9439100000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f9438efa000)
	libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f9438ce4000)
	libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f9438aa8000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f943889d000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f943869a000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f943848a000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f943827f000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f9438075000)
	libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f9437e72000)
	libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f9437c6e000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f9437a5c000)
	libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f94377b2000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f943750f000)
	libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f94372e9000)
	libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f94370e5000)
	libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f9436edc000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f9436cbd000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9436aa3000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f943689b000)
	libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007f9436692000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f943646e000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f9436253000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f943604a000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f9435e0c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f943ded4000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9435c08000)
	libcgmanager.so.0 => /lib/x86_64-linux-gnu/libcgmanager.so.0 (0x00007f94359ec000)
	libnih.so.1 => /lib/x86_64-linux-gnu/libnih.so.1 (0x00007f94357d4000)
	libnih-dbus.so.1 => /lib/x86_64-linux-gnu/libnih-dbus.so.1 (0x00007f94355ca000)
	libxcb-util.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-util.so.0 (0x00007f94353c2000)
	libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f94351c0000)
	libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007f9434f6a000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f9434d40000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f9434b3b000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f9434935000)
	libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1 (0x00007f943472e000)
	libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007f9434511000)

Of course the portions in brackets (mem addresses) will differ to yours.

bye
Ron

Last edited by GWR (2015-03-06 13:29:19)

ToZ · 2015-03-06 14:19:56

Your last listing (from the VM?) has a link to:

libxfce4util.so.7 => /usr/lib/x86_64-linux-gnu/libxfce4util.so.7 (0x00007f943c4fc000)

...which supersedes libxfce4util.so.6. My computer also links to version 7.

If I look at the PPA, I see that the libxfce4util package is not available for the precise tree, so if your system is based on Precise (12.04) then you will have the older library version. Version 7 of that library only appears to be available for Trusty (14.04) and Utopic (14.10). I'm not sure why that is the case.

To confirm, is your local computer based on Precise (12.04)? I thought I saw some stuff earlier that showed it was based on Trusty.

GWR · 2015-03-06 18:11:57

The "libxfce4util.so.6" is from my local computer - which is currently on "Linux Mint 17 Qiana" - which is based on ubuntu 14.04.

But! It is an upgrade from Petra (based on 13.10) or even Olivia (13.04) - am not sure if I reinstalled it between Olivia and Petra (home partition is separated so no big trouble then...). When switching from Xubuntu to Mint I completely reinstalled everything (just kept my documents/work data)

Both VMs (new install of Mint 17 and Mint 17.1) do not have a libxfce4util.so.* linked ... it is only listed with ldd on my local computer - and it seems on your too.

bye
Ron

Last edited by GWR (2015-03-06 18:13:39)

rworkman · 2015-03-07 07:24:52

Please try this and let me know if it makes a difference: http://www.slackware.com/~rworkman/0001 … INAR.patch

EDIT: It doesn't, but the idea behind it was good, it seems. Follow the bug report for more details.

Last edited by rworkman (2015-03-07 19:05:26)

ToZ · 2015-03-17 20:45:43

FYI: Looks like a fix has been found and patch released into the git tree. More info at the bug report: https://bugzilla.xfce.org/show_bug.cgi?id=11450

GWR · 2015-03-18 18:12:13

Meanwhile I had used the "switch binary filesize display on/off"-approach described in the ticket's responses.
Worked for most cases... still having odd crashes here and then (doing nothing, just refreshing) but if that happens more often I might report it "somehow".

Now I just need my "execute scripts marked as executable" back ... opening them in an editor is nonsense. Having many scripts I here and there want to execute (kick-off-scripts, asset-creation-scripts and the likes) is now very inconvenient (had to build simple binaries kicking of the shell scripts... *shivering* not the best solution ... but I get offtopic...).

@ToZ
Thanks for keeping us updated.

bye
Ron

ToZ · 2015-03-18 18:20:49

GWR wrote:

Now I just need my "execute scripts marked as executable" back ... opening them in an editor is nonsense. Having many scripts I here and there want to execute (kick-off-scripts, asset-creation-scripts and the likes) is now very inconvenient (had to build simple binaries kicking of the shell scripts... *shivering* not the best solution ... but I get offtopic...).

There is an xfconf setting (misc-exec-shell-scripts-by-default) that restores the old behaviour.

sixsixfive · 2015-03-18 23:39:33

GWR wrote:

opening them in an editor is nonsense.

Thats good how it is now, because you can not accidentally run something - an easy solution is a custom action eg: "x-terminal-emulator -e ./%n"

Last edited by sixsixfive (2015-03-18 23:39:49)

GWR · 2015-03-19 12:42:41

How could you accidentally run a script? You have to make it executable first. It is like making binaries not execute on default when somebody "double clicks" on that file in the file manager. At the end "script files" are nothing more than "text-file-based applications", and they should get handled that way.

Did I miss something in my thoughts?

@custom action
When right-clicking on a binary, the main action is displayed "run" ... why not do it similar for every executable binary? Just present an "run" (if not already an available option). Such things make life more convenient.
Thanks for the hint.

@Toz: hidden setting
never knew of such hidden thingies before... thanks a lot!. Added it and works like a charm. A pitty they hide such options - it does not cost many pennies to have such options available via "GUI" (advanced mode?).

bye
Ron

Last edited by GWR (2015-03-19 12:44:27)

sixsixfive · 2015-03-19 17:10:39

>How could you accidentally run a script?

enable one click navigation, use a touchpad, drag accidentally a file over the mimetype icon etc.

>You have to make it executable first.

not if you downloaded the script with git or extracted it from an archive that preserves rights. anyway, I like this but, I also would never run a script without a terminal since there is no indication what is going on...

>it does not cost many pennies to have such options available via "GUI" (advanced mode?).

they are all there, just open the windows regedit clone and edit the settings...

@custom action

I personally like how this is done in nautilus: you click on the icon and a dialog pops up to ask you if you would run the file or edit/view the file

Last edited by sixsixfive (2015-03-19 17:11:18)

GWR · 2015-03-24 07:01:29

I personally like how this is done in nautilus: you click on the icon and a dialog pops up to ask you if you would run the file or edit/view the file

Yes - if it remembers your decision ([ ] Remember my decision) - and eg. forgets about them after 3 months of not using the script (so the "memory/history" stays small). Of course thunar should then remember the "hash" of the executable to ask again if the file was changed (to avoid suspicious changes) - or add a "[x] execute regardless of potential changes to the file")

>How could you accidentally run a script?
enable one click navigation, use a touchpad, drag accidentally a file over the mimetype icon etc.

Yes... this is exactly a scenario which is defined and could get handled
- do only execute if the user does _not_ one-click-navigate
- touchpad allows to "tap 2 times"
- drag-drop -> this is is exactly how it should work: drop something on a binary and the binary (or executable file) should get the dropped thing as argument when it gets executed. Maybe this should be an [x]-option in the gui you have to activate. Also this feature needs to make sure that dropping files in the list view is working as it should (eg. you cannot right click on a "full of entries"-listview to create a new one, because it even reacts to whitespace in the columns - which might be having a "maxwidth" to allow reaction to very short filenames)

I also would never run a script without a terminal since there is no indication what is going on...

This is the same for console apps ... isn't it ?
It is up to you to run your scripts via console or not (adjust the scripts). Similar to binary apps you will have varying requirements (console? gui? ...).

@regedit clone
I never knew about it - but once you change a "prior working feature" you should not hide it in something the default user might not know - but was happily using some shell scripts to automate some tasks for him (eg. setting up wine-path, environment and then startup a .exe via wine) - some of them might even just have downloaded a shell-script, edited it according to some ubuntuusers-guide and were happy that they could "double click" on it.
Now you want them to google again without knowing what to search ("Cannot click on my start file anymore" or "My gameXY start file does not work anymore"). I understand that most of them would even _not_ be thinking of checking a file manager's option-dialogue - so the best of both worlds would be what you reminded us already - the nautilus-way of executing files. Just improve it the way I tried to describe (maybe it has flaws too?)

@sixsixfive
thanks for your additional input.

bye
Ron

MountainDewManiac · 2015-03-24 11:57:47

GWR wrote:

I personally like how this is done in nautilus: you click on the icon and a dialog pops up to ask you if you would run the file or edit/view the file
Yes - if it remembers your decision ([ ] Remember my decision) - and eg. forgets about them after 3 months of not using the script (so the "memory/history" stays small). Of course thunar should then remember the "hash" of the executable to ask again if the file was changed (to avoid suspicious changes) - or add a "[x] execute regardless of potential changes to the file")

Is it possible that Nautilus sets some bit or other in the file's "directory data?" There's probably room in it. Seems like I once read that there was more data (or space for data... ICRS) associated with a file than just its name, date, and file size. But I'm just guessing. IOW, somehow applies it as part of the file's own settings instead of as a part of Nautilus? One way to find out, I suppose, would be to set a few files each way on external media (USB drive, I guess) and then to check their behavior on a different computer. It just occurred to me that it might be tied in to a user's permissions/name, though (would make sense if it was). So... IDK, it'd probably have to be two setups where the user's name and permissions were the same so that it'd seem to be the same user (sort of), only different instances of Nautilus, obviously, since it'd be on a different computer (or, at least, a different partition).

I was thinking about installing Nautilus last night. I kind of miss being able to hover my mouse cursor over any audio file and it playing the audio as long as I did not move my cursor off the file's representation in the FM. Then again, it's a little thing (my current laptop is powerful enough that it doesn't tax it to just double-click on the file to launch its associated media player, lol) and I last used Nautilus in the GNOME 2.x days, so it has probably changed a lot since then. Besides, I like Thunar well enough, it seems to have other features that I expect in a FM - the addition of the tabs feature several versions ago was nice for moving/copying files and the like, and It has not had a problem creating thumbnails for all my files including video ones (also something that improved for me several versions ago) and seems to do so reasonably quickly... although possibly not quite as quickly as PCManFM, which created thumbnails as fast as any FM that I've used. But I digress.

Regards,
MDM

Xfce Forum

Sub domains

#26 2015-03-05 15:53:54

Re: Thunar 1.6.4 crashes when copying files

#27 2015-03-05 18:46:52

Re: Thunar 1.6.4 crashes when copying files

#28 2015-03-05 22:26:19

Re: Thunar 1.6.4 crashes when copying files

#29 2015-03-06 06:09:09

Re: Thunar 1.6.4 crashes when copying files

#30 2015-03-06 11:28:52

Re: Thunar 1.6.4 crashes when copying files

#31 2015-03-06 13:21:21

Re: Thunar 1.6.4 crashes when copying files

#32 2015-03-06 14:19:56

Re: Thunar 1.6.4 crashes when copying files

#33 2015-03-06 18:11:57

Re: Thunar 1.6.4 crashes when copying files

#34 2015-03-07 07:24:52

Re: Thunar 1.6.4 crashes when copying files

#35 2015-03-17 20:45:43

Re: Thunar 1.6.4 crashes when copying files

#36 2015-03-18 18:12:13

Re: Thunar 1.6.4 crashes when copying files

#37 2015-03-18 18:20:49

Re: Thunar 1.6.4 crashes when copying files

#38 2015-03-18 23:39:33

Re: Thunar 1.6.4 crashes when copying files

#39 2015-03-19 12:42:41

Re: Thunar 1.6.4 crashes when copying files

#40 2015-03-19 17:10:39

Re: Thunar 1.6.4 crashes when copying files

#41 2015-03-24 07:01:29

Re: Thunar 1.6.4 crashes when copying files

#42 2015-03-24 11:57:47

Re: Thunar 1.6.4 crashes when copying files

Board footer